| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| TOTOLINK X5000R v9.1.0cu_2415_B20250515 contains an argument injection vulnerability in the setDiagnosisCfg handler of the /usr/sbin/lighttpd executable. The ip parameter is retrieved via websGetVar and passed to a ping command through CsteSystem without validating if the input starts with a hyphen (-). This allows remote authenticated attackers to inject arbitrary command-line options into the ping utility, potentially leading to a Denial of Service (DoS) by causing excessive resource consumption or prolonged execution. |
| An issue pertaining to CWE-295: Improper Certificate Validation was discovered in YMFE yapi v1.12.0. The application disables TLS/SSL certificate validation by setting 'rejectUnauthorized': false in the HTTPS agent configuration for Axios requests |
| Buffer Overflow vulnerability in CDATA FD614GS3-R850 V3.2.7_P161006 (Build.0333.250211) allows an attacker to execute arbitrary code via the node_mac, node_opt, opt_param, and domainblk parameters of the mesh_node_config and domiainblk_config modules |
| Unrestricted Upload of File with Dangerous Type vulnerability in Bravis-Themes Bravis Addons bravis-addons allows Using Malicious Files.This issue affects Bravis Addons: from n/a through <= 1.1.9. |
| libtiff up to v4.7.1 was discovered to contain a double free via the component tools/tiffcrop.c. |
| libtiff up to v4.7.1 was discovered to contain a stack overflow via the readSeparateStripsIntoBuffer function. |
| libtiff up to v4.7.1 was discovered to contain a NULL pointer dereference via the component libtiff/tif_open.c. |
| Mercator is an open source web application designed to enable mapping of information systems. A stored Cross-Site Scripting (XSS) vulnerability exists in Mercator prior to version 2026.02.22 due to the use of unescaped Blade directives (`{!! !!}`) in display templates. An authenticated user with the User role can inject arbitrary JavaScript payloads into fields such as "contact point" when creating or editing entities. The payload is then executed in the browser of any user who views the affected page, including administrators. Version 2026.02.22 fixes the vulnerability. |
| 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. |
