Focus on sciencelogic vulnerabilities and metrics.
Last updated: 08 Mar 2025, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with sciencelogic. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total sciencelogic CVEs: 26
Earliest CVE date: 09 Aug 2023, 18:15 UTC
Latest CVE date: 18 Oct 2024, 15:15 UTC
Latest CVE reference: CVE-2024-9537
30-day Count (Rolling): 0
365-day Count (Rolling): 1
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): -96.0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): -96.0%
Average CVSS: 0.0
Max CVSS: 0
Critical CVEs (≥9): 0
Range | Count |
---|---|
0.0-3.9 | 26 |
4.0-6.9 | 0 |
7.0-8.9 | 0 |
9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for sciencelogic, sorted by severity first and recency.
ScienceLogic SL1 (formerly EM7) is affected by an unspecified vulnerability involving an unspecified third-party component packaged with SL1. The vulnerability is addressed in SL1 versions 12.1.3+, 12.2.3+, and 12.3+. Remediations have been made available for all SL1 versions back to version lines 10.1.x, 10.2.x, 11.1.x, 11.2.x, and 11.3.x.
A SQL injection vulnerability exists in the “logging export” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “message viewer iframe” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “message viewer print” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “network print report” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “notes view” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “reporter events type” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “reporter events type date” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “ticket event report” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “ticket queue watchers” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “ticket template watchers” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “ticket watchers email” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “topology data service” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the vendor_country parameter of the “vendor print report” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the vendor_state parameter of the “vendor print report” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “admin dynamic app mib errors” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “reporting job editor” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “schedule editor decoupled” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “schedule editor” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “json walker” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A SQL injection vulnerability exists in the “admin brand portal” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.
A command injection vulnerability exists in the download and convert report feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a shell command. This allows for the injection of arbitrary commands to the underlying operating system.
A command injection vulnerability exists in the dashboard scheduler feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a shell command. This allows for the injection of arbitrary commands to the underlying operating system.
A command injection vulnerability exists in the ticket report generate feature of the ScienceLogic SL1 that takes unsanitized user controlled input and passes it directly to a shell command. This allows for the injection of arbitrary commands to the underlying operating system.
A command injection vulnerability exists in the “dash export” feature of the ScienceLogic SL1 that takes unsanitized user controlled input and passes it directly to a shell command. This allows for the injection of arbitrary commands to the underlying operating system.
A command injection vulnerability exists in the ARP ping device tool feature of the ScienceLogic SL1 that takes unsanitized user controlled input and passes it directly to a shell command. This allows for the injection of arbitrary commands to the underlying operating system.