| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The AppPresser – Mobile App Framework plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'myappp_verify' function in all versions up to, and including, 4.5.0. This makes it possible for unauthenticated attackers to extract sensitive data including plugin and theme names and version numbers, which can be used to facilitate targeted attacks against outdated or vulnerable components. |
| The Keras.Model.load_model method, including when executed with the intended security mitigation safe_mode=True, is vulnerable to arbitrary local file loading and Server-Side Request Forgery (SSRF).
This vulnerability stems from the way the StringLookup layer is handled during model loading from a specially crafted .keras archive. The constructor for the StringLookup layer accepts a vocabulary argument that can specify a local file path or a remote file path.
* Arbitrary Local File Read: An attacker can create a malicious .keras file that embeds a local path in the StringLookup layer's configuration. When the model is loaded, Keras will attempt to read the content of the specified local file and incorporate it into the model state (e.g., retrievable via get_vocabulary()), allowing an attacker to read arbitrary local files on the hosting system.
* Server-Side Request Forgery (SSRF): Keras utilizes tf.io.gfile for file operations. Since tf.io.gfile supports remote filesystem handlers (such as GCS and HDFS) and HTTP/HTTPS protocols, the same mechanism can be leveraged to fetch content from arbitrary network endpoints on the server's behalf, resulting in an SSRF condition.
The security issue is that the feature allowing external path loading was not properly restricted by the safe_mode=True flag, which was intended to prevent such unintended data access. |
| Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') vulnerability in ABB Terra AC wallbox.This issue affects Terra AC wallbox: through 1.8.33. |
| In Search Guard FLX versions 3.1.1 and earlier, Field-Level Security (FLS) rules are improperly enforced on object-valued fields.
When an FLS exclusion rule (e.g., ~field) is applied to a field which contains an object as its value, the object is correctly removed from the _source returned by search operations. However, the object members (i.e., child attributes) remain accessible to search queries. This exposure allows adversaries to infer or reconstruct the original contents of the excluded object.
Workaround - If you cannot upgrade immediately and FLS exclusion rules are used for object valued attributes (like ~object), add an additional exclusion rule for the members of the object (like ~object.*). |
| In Search Guard versions 3.1.1 and earlier, Field Masking (FM) rules are improperly enforced on fields of type IP (IP Address).
While the content of these fields is properly redacted in the _source document returned by search operations, the results do return documents (hits) when searching based on a specific IP values. This allows to reconstruct the original contents of the field.
Workaround - If you cannot upgrade immediately, you can avoid the problem by using field level security (FLS) protection on fields of the affected types instead of field masking. |
| The LiteSpeed Cache plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via URLs in all versions up to, and including, 7.5.0.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. |
| This vulnerability allows an attacker to access parts of the application that are not protected by any type of access control. The attacker could access this path ‘…/epsilonnet/License/About.aspx’ and obtain information on both the licence and the configuration of the product by knowing which modules are installed. |
| The Blocksy Companion plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'blocksy_newsletter_subscribe' shortcode in all versions up to, and including, 2.1.14 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| CKAN is an open-source DMS (data management system) for powering data hubs and data portals. Prior to 2.10.9 and 2.11.4, the helpers.markdown_extract() function did not perform sufficient sanitization of input data before wrapping in an HTML literal element. This helper is used to render user-provided data on dataset, resource, organization or group pages (plus any page provided by an extension that used that helper function), leading to a potential XSS vector. This vulnerability has been fixed in CKAN 2.10.9 and 2.11.4. |
| This vulnerability affects NeuVector deployments only when the Report anonymous cluster data option is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server.
In affected versions, NeuVector does not enforce TLS
certificate verification when transmitting anonymous cluster data to the
telemetry server. As a result, the communication channel is susceptible
to man-in-the-middle (MITM) attacks, where an attacker could intercept
or modify the transmitted data. Additionally, NeuVector loads the
response of the telemetry server is loaded into memory without size
limitation, which makes it vulnerable to a Denial of Service(DoS)
attack |
| NeuVector used a hard-coded cryptographic key embedded in the source
code. At compilation time, the key value was replaced with the secret
key value and used to encrypt sensitive configurations when NeuVector
stores the data. |
| On affected platforms, restricted users could view sensitive portions of the config database via a debug API (e.g., user password hashes) |
| Cryptographic validation of upgrade images could be circumventing by dropping a specifically crafted file into the upgrade ISO |
| An unquoted service path in Kingosoft Technology Ltd Kingo ROOT v1.5.8.3353 allows attackers to escalate privileges via placing a crafted executable file into a parent folder. |
| An unauthenticated server-side request forgery (SSRF) vulnerability in the Thumbnail via-uri endpoint of Halo CMS 2.21 allows a remote attacker to cause the server to issue HTTP requests to attacker-controlled URLs, including internal addresses. The endpoint performs a server-side GET to a user-supplied URI without adequate allow/blocklist validation and returns a 307 redirect that can disclose internal URLs in the Location header. |
| DLL hijacking vulnerability in Evope Collector 1.1.6.9.0 and related components load the wtsapi32.dll library from an uncontrolled search path (C:\ProgramData\Evope). This allows local unprivileged attackers to execute arbitrary code or escalate privileges to SYSTEM by placing a crafted DLL in that location. The vulnerable component is Evope.Service.exe, which runs with SYSTEM privileges and automatically loads the DLL on startup or reboot. |
| An issue in NCR Atleos Terminal Manager (ConfigApp) v3.4.0 allows attackers to escalate privileges via a crafted request. |
| Improper Input Validation vulnerability in Salesforce Tableau Server on Windows, Linux (tabdoc api - create-data-source-from-file-upload modules) allows Absolute Path Traversal.This issue affects Tableau Server: before 2025.1.3, before 2024.2.12, before 2023.3.19. |
| Improper Neutralization of Input During Web Page Generation in Kibana can lead to Stored XSS via case file upload. |
| Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak.
Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted<T>` type to a new `OwnedRooted<T>` type. This change was integrated into Wasmtime's C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted<T>`, as the name implies, required manual calls to an "unroot" operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to "unroot" was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.
In migrating to `OwnedRooted<T>` the usage of the type in Rust changed. A manual "unroot" operation is no longer required and it happens naturally as a destructor of the `OwnedRooted<T>` type in Rust itself. These new resource ownership semantics were not fully integrated into the preexisting semantics of the C/C++ APIs in Wasmtime. A crucial distinction of `OwnedRooted<T>` vs `ManuallyRooted<T>` is that the `OwnedRooted<T>` type allocates host memory outside of the store. This means that if an `OwnedRooted<T>` is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host.
This led to a few distinct, but related, issues arising: A typo in the `wasmtime_val_unroot` function in the C API meant that it did not actually unroot anything. This meant that even if embedders faithfully call the function then memory will be leaked. If a host-defined function returned a `wasmtime_{externref,anyref}_t` value then the value was never unrooted. The C/C++ API no longer has access to the value and the Rust implementation did not unroot. This meant that any values returned this way were never unrooted. The goal of the C++ API of Wasmtime is to encode automatic memory management in the type system, but the C++ API was not updated when `OwnedRooted<T>` was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values.
These issues have all been fixed in a 37.0.2 release of Wasmtime. The implementation of the C and C++ APIs have been updated accordingly and respectively to account for the changes of ownership here. For example `wasmtime_val_unroot` has been fixed to unroot, the Rust-side implementation of calling an embedder-defined function will unroot return values, and the C++ API now has destructors on the `ExternRef`, `AnyRef`, and `Val` types. These changes have been made to the 37.0.x release branch in a non-API-breaking fashion. Changes to the 38.0.0 release branch (and `main` in the Wasmtime repository) include minor API updates to better accommodate the API semantic changes. The only known workaround at this time is to avoid using `externref` and `anyref` in the C/C++ API of Wasmtime. If avoiding those types is not possible then it's required for users to update to mitigate the leak issue. |
