| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Out-of-bounds Write vulnerability in praydog UEVR (dependencies/lua/src modules). This vulnerability is associated with program files ldebug.C, lvm.C.
This issue affects UEVR: before 1.05. |
| Out-of-bounds Read vulnerability in praydog UEVR (dependencies/lua/src modules). This vulnerability is associated with program files lparser.C.
This issue affects UEVR: before 1.05. |
| wlc is a Weblate command-line client using Weblate's REST API. Prior to 1.17.0, wlc supported providing unscoped API keys in the setting. This practice was discouraged for years, but the code was never removed. This might cause the API key to be leaked to different servers. |
| Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability:
* Use of Solr's "RuleBasedAuthorizationPlugin"
* A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles"
* A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read".
* A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission
* A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway)
Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1. |
| The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.
Solr deployments are subject to this vulnerability if they meet the following criteria:
* Solr is running in its "standalone" mode.
* Solr's "allowPath" setting is being used to restrict file access to certain directories.
* Solr's "create core" API is exposed and accessible to untrusted users. This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.
Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores. Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue. |
| Out-of-bounds Write vulnerability in Apache Hadoop HDFS native client.
This issue affects Apache Hadoop: from 3.2.0 before 3.4.2.
Users are recommended to upgrade to version 3.4.2, which fixes the issue. |
| Deserialization of Untrusted Data vulnerability in Apache Karaf Decanter.
The Decanter log socket collector exposes the port 4560, without authentication. If the collector exposes allowed classes property, this configuration can be bypassed.
It means that the log socket collector is vulnerable to deserialization of untrusted data, eventually causing DoS.
NB: Decanter log socket collector is not installed by default. Users who have not installed Decanter log socket are not impacted by this issue.
This issue affects Apache Karaf Decanter before 2.12.0.
Users are recommended to upgrade to version 2.12.0, which fixes the issue. |
| ** UNSUPPORTED WHEN ASSIGNED ** Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in Apache Continuum.
This issue affects Apache Continuum: all versions.
Attackers with access to the installations REST API can use this to invoke arbitrary commands on the server.
As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.
NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| Enhancesoft osTicket versions 1.18.x prior to 1.18.3 and 1.17.x prior to 1.17.7 contain an arbitrary file read vulnerability in the ticket PDF export functionality. A remote attacker can submit a ticket containing crafted rich-text HTML that includes PHP filter expressions which are insufficiently sanitized before being processed by the mPDF PDF generator during export. When the attacker exports the ticket to PDF, the generated PDF can embed the contents of attacker-selected files from the server filesystem as bitmap images, allowing disclosure of sensitive local files in the context of the osTicket application user. This issue is exploitable in default configurations where guests may create tickets and access ticket status, or where self-registration is enabled. |
| A vulnerability has been identified in the ServiceNow AI Platform that could enable an unauthenticated user to impersonate another user and perform the operations that the impersonated user is entitled to perform.
ServiceNow has addressed this vulnerability by deploying a relevant security update to hosted instances in October 2025. Security updates have also been provided to ServiceNow self-hosted customers, partners, and hosted customers with unique configurations. Additionally, the vulnerability is addressed in the listed Store App versions. We recommend that customers promptly apply an appropriate security update or upgrade if they have not already done so. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 18.3 and iPadOS 18.3. An app may be able to enumerate a user's installed apps. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 18.3 and iPadOS 18.3. An app may be able to enumerate a user's installed apps. |
| This issue was addressed through improved state management. This issue is fixed in iOS 18.1 and iPadOS 18.1. A user may be able to view restricted content from the lock screen. |
| The issue was addressed with improved bounds checks. This issue is fixed in iOS 18.1 and iPadOS 18.1. An app may be able to corrupt coprocessor memory. |
| This issue was addressed with improved permissions checking. This issue is fixed in macOS Sequoia 15.1. An app may be able to access user-sensitive data. |
| Multiple SQL Injection vulnerabilities exist in AbhishekMali21 GYM-MANAGEMENT-SYSTEM 1.0 via the 'name' parameter in (1) member_search.php, (2) trainer_search.php, and (3) gym_search.php, and via the 'id' parameter in (4) payment_search.php. An unauthenticated remote attacker can exploit these issues to inject malicious SQL commands, leading to unauthorized data extraction, authentication bypass, or modification of database contents. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in Xcode 16.3. An app may be able to bypass Privacy preferences. |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Tahoe 26.1. An app may be able to access sensitive user data. |
| In cpm_fwtp_msg_handler of cpm/google/lib/tracepoint/cpm_fwtp_ipc.c, there is a possible memory overwrite due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| SAP HANA database is vulnerable to privilege escalation allowing an attacker with valid credentials of any user to switch to another user potentially gaining administrative access. This exploit could result in a total compromise of the system�s confidentiality, integrity, and availability. |
