CVE Vulnerability Catalog

From 4.1.11 until 4.1.12 and 5.0.3, isFileLoadingAllowed and the filesystem read interpret backslashes differently on Windows in packages/mocker/src/node/interceptorPlugin.ts in Vitest. When a client can reach the Vite dev server on Windows and register a redirect mock containing backslash traversal, POSIX joining preserves a Windows backslash traversal that the later filesystem read interprets as a path separator, so the client can read a file outside server.fs.allow that the Vitest process can access.

From 2.1.0-beta.7 until 4.1.12 and 5.0.3, an unauthenticated non-browser WebSocket client that can reach a development server using interceptorPlugin in Vitest can register a manual mock whose attacker-controlled url createManualModuleSource inserts unescaped into generated module source. When the developer browser loads the affected module, attacker-controlled JavaScript executes on the development-server origin.

Vitest from 5.0.0-beta.6 until 5.0.5 misapplies server.fs.deny because project servers replace Vite's defaults and the root server adds .vitest-secret-token after Vite compiles its matcher. An attacker who can reach an affected UI, Browser Mode, or API server can read denied project files or the fallback API token at node_modules/.vitest/.vitest-secret-token, and Browser Mode with test.projects can expose JavaScript-compatible .env values through a malicious website.

Vite from 8.2.0 until 8.2.4 and 8.3.3 can return the first 4 bytes of files outside the server.fs setting to the browser via a request containing ?vite-wasm-instance. The internal Wasm plugin's load hook removes the query and reads the path directly from disk without applying server.fs checks, and a WebAssembly parse error discloses the first 4 bytes of the file.

Vite prior to 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3 can record a root-relative browser URL in safeModulePaths instead of the cleaned resolved module identifier. On a network-accessible, non-Windows development server, an imported project file whose URL matches an absolute host path can authorize a later raw-filesystem request for that host file, provided server.fs.deny does not block it.

The WordPress SureCart plugin through 4.9.5 contains a Cross-site Scripting (Stored XSS) vulnerability due to improper neutralization of input during web page generation. This may allow injection of a malicious script that is stored and executed by other users.

The WordPress Booktics plugin through 1.0.30 contains a Missing Authorization vulnerability that allows exploitation of incorrectly configured access control security levels. This may allow unauthorized users to perform restricted actions.

The WordPress Bus Ticket Booking with Seat Reservation plugin through 5.9.7 contains a Missing Authorization vulnerability that allows exploitation of incorrectly configured access control security levels. This may allow unauthorized users to perform restricted actions.

The WordPress WP User Manager plugin through 2.9.25 contains a Missing Authorization vulnerability that allows manipulating user state. This may allow unauthorized users to change the state of other users' accounts.

The WordPress Rootblox plugin through 1.0.7 contains a Cross-site Scripting (Stored XSS) vulnerability due to improper neutralization of input during web page generation. This may allow injection of a malicious script that is stored and executed by other users.

A2A Java SDK prior to 1.3.0.Final allows a malicious or compromised remote agent to cause the default JDK-based client to forward a configured API key to a third-party server. AuthInterceptor uses APIKeySecurityScheme.name() from the remote AgentCard as the HTTP header name without checking that the declared location is HEADER, and JdkA2AHttpClient uses followRedirects(NORMAL), so an agent-controlled cross-origin redirect forwards the credential-bearing header.

The WordPress Meta Box – WordPress Custom Fields Framework plugin through 5.15.2 contains a Missing Authorization vulnerability that allows exploitation of incorrectly configured access control security levels. This may allow unauthorized users to perform restricted actions.

Apache CouchDB 3.5.2 and below insufficiently filters credentials in the _replicator database. An authenticated user can read replication credentials of other users' replications, not just their own.

In Eclipse OpenJ9 versions up to 0.63, opening a supplied diagnostic dump bundle with the jdmpview tool or equivalent DTFJ code may cause the analyst's machine to read an arbitrary local file named inside the bundle and send its contents to an arbitrary remote host.

A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page.

In a memory-protected ThreadX module, a queue request reaches the Module Manager's dispatch layer, which passes a word count instead of a byte extent to the range check. This causes a privileged read of up to 3 * message_size bytes past the module's allowed memory, with the data written into the queue's message area.

The GUIX software JPEG decoder reads four kinds of marker segments without checking that each is long enough to hold what it reads. A truncated segment causes a read past the caller's image buffer, and a zero chroma sampling factor makes the block decode loop non-terminating.

_gx_binres_pixelmap_table_load() in the GUIX binary resource (theme) loader indexes the pixelmap table with a value read verbatim from the resource file and never bounds it against the table size. A crafted theme drives a write of up to roughly 256 KB past the end of the table, corrupting GUIX's own memory arena.

gx_binres_theme_load() and gx_binres_font_load() take the resource as a bare GX_UBYTE * with no length, and GX_BINRES_DATA_INFO has no field to carry one. A resource declaring more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded.

The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file placing a second SOF0 frame header after SOS re-runs the frame header parser after the output buffer has been allocated, and the decoder returns GX_SUCCESS and publishes a GX_PIXELMAP whose dimensions and data_size exceed the allocation.