| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| SAP Financial Consolidation - version 1010,�does not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges. |
| 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. |
| Astro is a web framework. In versions 9.0.0 through 9.5.3, Astro server actions have no default request body size limit, which can lead to memory exhaustion DoS. A single large POST to a valid action endpoint can crash the server process on memory-constrained deployments. On-demand rendered sites built with Astro can define server actions, which automatically parse incoming request bodies (JSON or FormData). The body is buffered entirely into memory with no size limit — a single oversized request is sufficient to exhaust the process heap and crash the server. Astro's Node adapter (`mode: 'standalone'`) creates an HTTP server with no body size protection. In containerized environments, the crashed process is automatically restarted, and repeated requests cause a persistent crash-restart loop. Action names are discoverable from HTML form attributes on any public page, so no authentication is required. The vulnerability allows unauthenticated denial of service against SSR standalone deployments using server actions. A single oversized request crashes the server process, and repeated requests cause a persistent crash-restart loop in containerized environments. Version 9.5.4 contains a fix. |
| Astro is a web framework. Prior to version 9.5.4, Server-Side Rendered pages that return an error with a prerendered custom error page (eg. `404.astro` or `500.astro`) are vulnerable to SSRF. If the `Host:` header is changed to an attacker's server, it will be fetched on `/500.html` and they can redirect this to any internal URL to read the response body through the first request. An attacker who can access the application without `Host:` header validation (eg. through finding the origin IP behind a proxy, or just by default) can fetch their own server to redirect to any internal IP. With this they can fetch cloud metadata IPs and interact with services in the internal network or localhost. For this to be vulnerable, a common feature needs to be used, with direct access to the server (no proxies). Version 9.5.4 fixes the issue. |
| Improper Validation of Specified Quantity in Input in GitHub repository vim/vim prior to 9.0.0218. |
| Authorization Bypass Through User-Controlled Key in GitHub repository openemr/openemr prior to 7.0.0.1. |
| Session Fixation in GitHub repository namelessmc/nameless prior to v2.0.2. |
| Improper Removal of Sensitive Information Before Storage or Transfer in GitHub repository cockpit-hq/cockpit prior to 2.2.2. |
| A vulnerability was found in erzhongxmu JEEWMS up to 3.7. This affects an unknown part of the file src/main/webapp/plug-in/ueditor/jsp/getContent.jsp of the component UEditor. The manipulation of the argument myEditor results in cross site scripting. The attack can be launched remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Missing Authorization in GitHub repository openemr/openemr prior to 7.0.0.1. |
| Incorrect Privilege Assignment vulnerability in Hitachi Hitachi Storage Plug-in for VMware vCenter allows remote authenticated users to cause privilege escalation.This issue affects Hitachi Storage Plug-in for VMware vCenter: from 04.8.0 before 04.9.0. |
| Improper Control of Generation of Code ('Code Injection') in GitHub repository hestiacp/hestiacp prior to 1.6.6. |
| Out-of-bounds Write to API in GitHub repository vim/vim prior to 9.0.0100. |
| Inefficient Regular Expression Complexity in GitHub repository node-fetch/node-fetch prior to 3.2.10. |
| Authentication Bypass by Spoofing in GitHub repository microweber/microweber prior to 1.2.20. |
| libtpms, a library that provides software emulation of a Trusted Platform Module, has a flaw in versions 0.10.0 and 0.10.1. The commonly used integration of libtpms with OpenSSL 3.x contained a vulnerability related to the returned IV (initialization vector) when certain symmetric ciphers were used. Instead of returning the last IV it returned the initial IV to the caller, thus weakening the subsequent encryption and decryption steps. The highest threat from this vulnerability is to data confidentiality. Version 0.10.2 fixes the issue. No known workarounds are available. |
| Code Injection in GitHub repository nuitka/nuitka prior to 0.9. |
| A vulnerability was detected in FastApiAdmin up to 2.2.0. This vulnerability affects the function upload_file_controller of the file /backend/app/api/v1/module_system/params/controller.py of the component Scheduled Task API. Performing a manipulation results in unrestricted upload. The attack can be initiated remotely. The exploit is now public and may be used. |
| Versions of the Traccar open-source GPS tracking system starting with 6.11.1 contain an issue in which authenticated users can execute arbitrary JavaScript in the context of other users' browsers by uploading malicious SVG files as device images. The application accepts SVG file uploads without sanitization and serves them with the `image/svg+xml` Content-Type, allowing embedded JavaScript to execute when victims view the image. As of time of publication, it is unclear whether a fix is available. |
| Due to an uncontrolled recursion in SAP Web Dispatcher and SAP Internet Communication Manager, the application may crash, leading to denial of service, but can be restarted automatically. |
