| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability was found in Shaoxing Background Management System. It has been declared as critical. This vulnerability affects unknown code of the file /Default/Bd. The manipulation of the argument id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-214774 is the identifier assigned to this vulnerability. |
| Due to improper input validation in the Alerts controller, a SQL injection vulnerability in Nozomi Networks Guardian and CMC allows an authenticated attacker to execute arbitrary SQL queries on the DBMS used by the web application. |
| A vulnerability, which was classified as critical, was found in Sports Club Management System 119. This affects an unknown part of the file admin/make_payments.php. The manipulation of the argument m_id/plan leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-213789 was assigned to this vulnerability. |
| 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. |
