CVE-2023-44449

What it actually does

The flaw is an authenticated SQL injection in the clearAlertByIds function, where user-controlled input is concatenated into SQL queries without sufficient validation or parameterization. A low-privileged authenticated attacker can manipulate the query executed by the application database account, potentially reading sensitive data, changing records, modifying authorization data, or disrupting database-backed application functions. Because the CVSS vector is network-accessible, low-complexity, requires no user interaction, and has high confidentiality, integrity, and availability impact, successful exploitation can become full application-level compromise if the database account has broad privileges.

Why it matters to the business

An attacker with any valid account could abuse the affected management function to gain higher privileges, access or alter sensitive operational data, interfere with alerting or monitoring workflows, and potentially take over administrative functions. Although it is not listed in CISA KEV and no mature public exploit is indicated, the EPSS score is elevated, the issue has been public for a long period, and the impact is high, so internet- or partner-accessible deployments should be treated as urgent. Supplied fixed-version metadata references strapi/strapi Git commit d36609ff26fb4e00a41a7e2b657f16c7466203fe; organizations should verify product applicability against vendor advisories because the descriptive vulnerability details refer to NETGEAR ProSAFE Network Management System.

How an attack unfolds

An attacker first obtains or compromises a low-privileged account that can reach the vulnerable application. They then access the alert-clearing workflow and submit a crafted value to the clearAlertByIds function, placing SQL syntax where the application expects an alert identifier or list of identifiers. Because the application builds a SQL statement directly from that input, the database interprets attacker-controlled SQL as part of the query. The attacker can use error responses, timing differences, or returned application behavior to confirm injection and then enumerate database structure. With enough access, they may read sensitive tables, alter user or role records, grant themselves administrative permissions, create persistence through new accounts or tokens, disable or modify alert data, and cover tracks by changing or deleting audit-relevant records.

How to fix it

Apply the vendor-supported fixed release for the affected product as soon as possible. Where the supplied package metadata applies, update strapi/strapi Git deployments to a build containing commit d36609ff26fb4e00a41a7e2b657f16c7466203fe or a later vendor-maintained release. For NETGEAR ProSAFE Network Management System deployments, consult NETGEAR advisories and upgrade to the vendor-fixed version for the clearAlertByIds SQL injection. If immediate patching is not possible, restrict access to the management interface to trusted administrative networks or VPNs, disable or limit low-privileged access to alert-clearing features, enforce strong authentication and account hygiene, and monitor for SQL injection payloads. Long-term code-level remediation should use parameterized queries or prepared statements, strict server-side type validation for identifier lists, least-privilege database accounts, and centralized input handling.

How to confirm the fix worked

Confirm that the deployed version or source build contains the vendor fix, including commit d36609ff26fb4e00a41a7e2b657f16c7466203fe where applicable. Review dependency lockfiles, container images, appliance firmware/software versions, and running service banners to ensure the vulnerable build is no longer deployed. In a controlled non-production environment, verify that malformed alert ID input containing quotes, comment markers, UNION clauses, or timing functions is rejected or safely parameterized and does not alter SQL execution. Confirm that low-privileged accounts cannot modify roles, users, tokens, or protected resources through the alert-clearing workflow. Review database permissions to ensure the application account cannot perform unnecessary schema changes or broad updates to security-sensitive tables.

Typical attack path

1. Identify an exposed or reachable affected application instance.
2. Obtain valid low-privileged credentials through registration, phishing, credential reuse, or prior compromise.
3. Access the alert management functionality that invokes clearAlertByIds.
4. Submit crafted alert ID values containing SQL control characters or expressions.
5. Use application responses, SQL errors, or timing behavior to confirm injection.
6. Enumerate database schema and identify user, role, session, token, alert, or configuration records.
7. Modify authorization data or create privileged access to escalate from low privilege to administrator-level control.
8. Use elevated privileges to access sensitive data, alter monitoring state, disrupt operations, or establish persistence.
9. Attempt to remove or obscure evidence by deleting alerts, changing audit-relevant records, or blending activity with normal authenticated traffic.

How to detect it

Investigate whether exploitation has already occurred by correlating web access logs, application logs, authentication logs, database audit logs, and administrative change records. Focus on authenticated requests to the clearAlertByIds function or alert-clearing endpoint that include SQL metacharacters, encoded quotes, comments, UNION statements, boolean tests, stacked queries, or time-delay functions. Look for SQL error messages shortly after alert-clearing actions, unusual HTTP 500 responses, repeated requests with slightly varied payloads, or long-running database queries tied to the application account. Review database audit trails for unexpected SELECT, UPDATE, INSERT, DELETE, ALTER, or privilege-related operations against user, role, token, session, configuration, or alert tables. Examine application records for new administrative users, changed role memberships, modified passwords, newly issued API tokens, disabled alerts, bulk-cleared alerts, or deleted audit data. Because exploitation requires authentication, correlate suspicious requests with source IPs, user accounts, session IDs, impossible travel, abnormal login times, and accounts that later gained elevated privileges.

• clearAlertByIds
• clearAlertByIds=
• clearAlertByIds%28
• UNION SELECT
• union select
• %55%4e%49%4f%4e%20%53%45%4c%45%43%54
• ' OR '1'='1
• " OR "1"="1
• OR 1=1
• %27%20OR%20%271%27%3D%271
• --
• %2D%2D
• /*
• %2F%2A
• SLEEP(
• sleep(
• WAITFOR DELAY
• waitfor delay
• BENCHMARK(
• benchmark(
• information_schema
• pg_catalog
• sqlite_master
• SQL syntax
• syntax error at or near
• You have an error in your SQL syntax
• unterminated quoted string
• ORA-01756
• Microsoft OLE DB Provider for SQL Server

What your security team should do

• Prioritize patching or compensating controls for any internet-accessible or broadly reachable management interface because exploitation is low-complexity after authentication and EPSS is elevated.
• Validate asset ownership and product applicability, since the provided metadata contains a mismatch between the NETGEAR ProSAFE vulnerability description and strapi/strapi fixed commit information.
• Restrict access to administrative and alert-management endpoints to trusted networks, VPNs, or privileged users until remediation is complete.
• Hunt for prior exploitation using web, application, authentication, and database audit logs, focusing on authenticated requests to clearAlertByIds containing SQL metacharacters or unusual query behavior.
• Review recently created users, privilege changes, API tokens, sessions, role assignments, and alert-deletion activity for unauthorized changes.
• Ensure database accounts used by the application are least-privileged and cannot modify authentication, authorization, or schema data beyond what the application requires.
• Add detection rules for SQL injection payloads in authenticated management requests and alert on suspicious successful requests followed by privilege changes.
• If exploitation is suspected, rotate affected credentials and tokens, preserve logs, snapshot relevant systems for forensics, and rebuild from known-good patched images where necessary.