| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A Reflected Cross Site Scripting (XSS) Vulnerability was discovered in Adrenalin 5.4 HRMS Software. The user supplied input containing JavaScript is echoed back in JavaScript code in an HTML response via the ShiftEmployeeSearch.aspx prntFrmName or prntDDLCntrlName parameter. |
| Adrenalin HRMS version 5.4.0 contains a Reflected Cross Site Scripting (XSS) vulnerability in the ApplicationtEmployeeSearch page via 'prntDDLCntrlName' and 'prntFrmName'. |
| A Reflected Cross Site Scripting (XSS) Vulnerability was discovered in Adrenalin 5.4.0 HRMS Software. The user supplied input containing JavaScript is echoed back in JavaScript code in an HTML response via the flexiportal/GeneralInfo.aspx strAction parameter. |
| SPIP versions prior to 4.4.10 contain an authentication bypass vulnerability caused by PHP type juggling that allows unauthenticated attackers to access protected information. Attackers can exploit loose type comparisons in authentication logic to bypass login verification and retrieve sensitive internal data. |
| A Improper Control of Generation of Code ('Code Injection') vulnerability in groovy script function in SmartRobot′s Conversational AI Platform before v7.2.0 allows remote authenticated users to perform arbitrary system commands via Groovy code. |
| Inefficient Regular Expression Complexity (CWE-1333) in the AI Inference Anonymization Engine in Kibana can lead Denial of Service via Regular Expression Exponential Blowup (CAPEC-492). |
| Improper Validation of Specified Quantity in Input (CWE-1284) in Kibana can allow an authenticated attacker with view-only privileges to cause a Denial of Service via Input Data Manipulation (CAPEC-153). An attacker can send a specially crafted, malformed payload causing excessive resource consumption and resulting in Kibana becoming unresponsive or crashing. |
| Improper Input Validation (CWE-20) in the internal Content Connectors search endpoint in Kibana can lead Denial of Service via Input Data Manipulation (CAPEC-153) |
| SPIP versions prior to 4.4.10 contain a SQL injection vulnerability that allows authenticated low-privilege users to execute arbitrary SQL queries by manipulating union-based injection techniques. Attackers can exploit this SQL injection flaw combined with PHP tag processing to achieve remote code execution on the server. |
| WebSocket endpoints lack proper authentication mechanisms, enabling
attackers to perform unauthorized station impersonation and manipulate
data sent to the backend. An unauthenticated attacker can connect to the
OCPP WebSocket endpoint using a known or discovered charging station
identifier, then issue or receive OCPP commands as a legitimate charger.
Given that no authentication is required, this can lead to privilege
escalation, unauthorized control of charging infrastructure, and
corruption of charging network data reported to the backend. |
| User Interface (UI) Misrepresentation of Critical Information vulnerability in OpenText™ Directory Services allows Cache Poisoning.
The vulnerability could be exploited by a bad actor to inject manipulated text into the OpenText application, potentially misleading users.
This issue affects Directory Services: from 20.4.1 through 25.2. |
| Tanium addressed a SQL injection vulnerability in Asset. |
| Tanium addressed a use-after-free vulnerability in the Cloud Workloads Enforce client extension. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in TanOS. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Trends. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Interact and TDS. |
| The WebSocket Application Programming Interface lacks restrictions on
the number of authentication requests. This absence of rate limiting may
allow an attacker to conduct denial-of-service attacks by suppressing
or mis-routing legitimate charger telemetry, or conduct brute-force
attacks to gain unauthorized access. |
| Fleet is open source device management software. In versions prior to 4.80.1, a vulnerability in Fleet’s Android MDM Pub/Sub handling could allow unauthenticated requests to trigger device unenrollment events. This may result in unauthorized removal of individual Android devices from Fleet management. If Android MDM is enabled, an attacker could send a crafted request to the Android Pub/Sub endpoint to unenroll a targeted Android device from Fleet without authentication. This issue does not grant access to Fleet, allow execution of commands, or provide visibility into device data. Impact is limited to disruption of Android device management for the affected device. Version 4.80.1 fixes the issue. If an immediate upgrade is not possible, affected Fleet users should temporarily disable Android MDM. |
| Fleet is open source device management software. In versions prior to 4.80.1, a vulnerability in Fleet’s configuration API could expose Google Calendar service account credentials to authenticated users with low-privilege roles. This may allow unauthorized access to Google Calendar resources associated with the service account. Fleet returns configuration data through an API endpoint that is accessible to authenticated users, including those with the lowest-privilege “Observer” role. In affected versions, Google Calendar service account credentials were not properly obfuscated before being returned. As a result, a low-privilege user could retrieve the service account’s private key material. Depending on how the Google Calendar integration is configured, this could allow unauthorized access to calendar data or other Google Workspace resources associated with the service account. This issue does not allow escalation of privileges within Fleet or access to device management functionality. Version 4.80.1 patches the issue. If an immediate upgrade is not possible, administrators should remove the Google Calendar integration from Fleet and rotate the affected Google service account credentials. |
| Fleet is open source device management software. In versions prior to 4.80.1, Fleet generated device lock and wipe PINs using a predictable algorithm based solely on the current Unix timestamp. Because no secret key or additional entropy was used, the resulting PIN could potentially be derived if the approximate time the device was locked is known. Fleet’s device lock and wipe commands generate a 6-digit PIN that is displayed to administrators for unlocking a device. In affected versions, this PIN was deterministically derived from the current timestamp. An attacker with physical possession of a locked device and knowledge of the approximate time the lock command was issued could theoretically predict the correct PIN within a limited search window. However, successful exploitation is constrained by multiple factors: Physical access to the device is required, the approximate lock time must be known, the operating system enforces rate limiting on PIN entry attempts, attempts would need to be spread over, and device wipe operations would typically complete before sufficient attempts could be made. As a result, this issue does not allow remote exploitation, fleet-wide compromise, or bypass of Fleet authentication controls. Version 4.80.1 contains a patch. No known workarounds are available. |
