Is CVE-2021-42258 (BQE BillQuick Web Suite SQL Injection) being exploited in the wild?

Yes. CISA added CVE-2021-42258 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. BQE BillQuick Web Suite contains an SQL injection vulnerability when accessing the username parameter that may allow for unauthenticated, remote code execution.

How CISA-Listed Exploitation Changes the Answer

CISA’s inclusion of a CVE in the Known Exploited Vulnerabilities catalogue is a strong indicator that exploitation is not theoretical. For defenders, that shifts the question from “is this vulnerability interesting?” to “can we find it, contain it, and prove whether it was used against us?” For SQL injection flaws, the first concern is whether the vulnerable application is reachable from untrusted networks and whether authentication or application logic exposed the risky parameter path.

A practical response starts with confirming exposure against the exact product and component named in the advisory, then prioritising remediation on any internet-facing instance. When the vulnerability can support unauthenticated remote code execution, the blast radius is broader than data theft alone: the attacker may be able to execute commands, drop payloads, or pivot to adjacent systems if the application has strong network reach or privileged backend access.

For a deeper operational view of how active exploitation should change triage, use the Zero-Day and Exploited Vulnerabilities Guide to align urgency with KEV status, exploitability and post-patch hunting.

What To Check Before You Assume You Are Safe

Do not stop at “patched” or “not patched.” Confirm whether the vulnerable code path was ever exposed, whether the asset was internet-facing, whether the application sat behind a reverse proxy or WAF, and whether logs show suspicious requests to the affected parameter. If the environment includes shared credentials, database links, file upload features or privileged service identities, SQL injection can become a route to wider compromise rather than a single-application issue.

The right evidence is usually a combination of access logs, application logs, database activity, host telemetry and any available command execution traces. If the service accepted crafted input before the fix, look for signs of enumeration, unusual user creation, outbound connections, unexpected child processes, or database queries that do not match normal application behaviour. A clean patch does not prove a clean history.

For investigation and hardening of the backend layer, the SQL Injection Prevention Guide and the Database Security Guide help connect application flaws to database privilege, auditing and detection.

Why Exploited SQL Injection Demands More Than Patching

When a SQL injection issue is already known to be exploited in the wild, patching is necessary but not sufficient. Attackers commonly target high-value web applications because SQL injection can provide a direct path to authentication bypass, data access, or code execution if the backend is configured loosely. In those cases, the exploit is not just a vulnerability in the web layer, it is a potential compromise of the whole trust boundary between the application and its data store.

If the application account has excessive database rights, the impact can extend into schema manipulation, credential theft, or stored procedure abuse. If the application also reaches internal services, the incident response scope should include lateral movement possibilities, not only the web server itself. The safest posture is to assume that a remotely exploitable SQL injection flaw may have exposed both data and operational control paths until evidence shows otherwise.

For prioritisation and verification discipline, the Vulnerability Management Guide is useful for deciding how KEV status, exploitability and remediation evidence should drive sequencing.

Risk and Threat Considerations

Exploited SQL injection creates immediate exposure because the attack path can start with a single crafted request and end with data access, session compromise, or remote code execution. In a KEV-listed case, the threat concern is not just theoretical exploitability, but evidence that adversaries are already using the flaw operationally, often before slower remediation cycles have completed.

Failure mechanism: The vulnerable parameter is processed by the application in a way that lets attacker-controlled input alter a backend SQL query, which can expose authentication data, application data, or execution paths the application never intended to reveal.

Impact: An attacker may steal data, tamper with records, bypass controls, execute code on the host, or use the application as a stepping stone into adjacent systems and secrets.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require continuous identification and prioritisation.
Recommendation — Prioritise KEV-listed flaws for immediate remediation and validation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about confirming and responding to a known exploited vulnerability.
Recommendation — Scan exposed assets and verify whether the vulnerable service is still reachable.
OWASP ASVS	V8 — Authorization	SQL injection can bypass intended access checks and alter backend authorization outcomes.
	V4 — API and Web Service	The vulnerable path is a web application input point that must resist injection abuse.
	V15 — Secure Coding and Architecture	Preventing SQL injection depends on secure query construction and architectural safeguards.
Recommendation — Verify that backend queries and data access paths cannot be altered by user input. Validate server-side request handling and parameter binding on exposed endpoints. Use parameterized queries and least-privilege database access by design.

Practitioner Guidance

What to prioritise: Treat KEV inclusion as a triage trigger, not just a patch note. Prioritise exposed production instances, especially any system with database reach, privileged service accounts, or external connectivity.

What to verify: Confirm whether the application ever accepted traffic to the vulnerable path, whether the database account had more privilege than the application truly needed, and whether logs show probe patterns or command execution after suspicious requests. If patch timing is uncertain, assume compromise was possible until disproven.

Practitioner takeaway: For an actively exploited SQL injection, the decisive question is not whether the fix exists, but whether the vulnerable path was reachable long enough to warrant compromise hunting and credential or session review.