Is CVE-2019-1068 (Microsoft SQL Server Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2019-1068 to its Known Exploited Vulnerabilities catalogue on 26 August 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft SQL Server contains a remote code execution vulnerability that could allow an attacker to execute code in the context of the SQL Server Database Engine service account.

What it means when CVE-2019-1068 is actively exploited

CISA’s inclusion of this SQL Server issue in KEV is the practical signal that matters: the vulnerability is no longer just a disclosure or a theoretical risk. For defenders, the question shifts from whether the flaw exists to whether any SQL Server instance is exposed, reachable, and still able to execute attacker-supplied code under the Database Engine service account.

Active exploitation also changes how you triage the finding. A remote code execution flaw in a database service can be used for more than one outcome, including initial foothold, command execution, data access, or preparation for lateral movement. That makes exposure inventory and ownership more important than generic patch backlog handling.

How to confirm and contain exposure

Start by identifying every SQL Server deployment that could plausibly be affected, including production, test, failover, and internet-facing instances. If you are using Database Security Guide as a baseline, treat this as a live exposure question rather than a configuration review exercise: the asset must be known, reachable, and owned before remediation can be trusted.

Then use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog to verify the current remediation requirement for your environment. If patching is delayed, remove external reachability, restrict administrative paths, and make sure compensating controls are not being assumed without evidence.

What good remediation looks like after a KEV listing

A KEV-listed database flaw should trigger more than installation of a fix. You should confirm whether the instance was reachable before remediation, whether the service account had broad filesystem, network, or domain privileges, and whether the system has logs that can show suspicious command execution or unusual child processes around the exposure window.

For broader prioritisation, pair the KEV signal with vulnerability management discipline rather than ad hoc patching. The most useful rule is to treat exploited vulnerabilities as time-sensitive security work, not routine maintenance, and to use Vulnerability Management Guide for asset scope, exception handling, and post-remediation verification.

Risk and Threat Considerations

When a remotely exploitable SQL Server issue is being used in the wild, the main risk is not just service disruption. Attackers can use database service execution to gain code execution in a trusted server context, then pivot into stored data, dependent applications, or adjacent infrastructure.

Failure mechanism: The flaw gives an attacker a path to execute code through the SQL Server Database Engine service account, so exploitation can convert a network-facing vulnerability into meaningful system-level access.

Impact: That access can expose data, enable persistence, or create a launch point for broader compromise, especially if the database service account has excessive local or domain privileges.

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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes vulnerability prioritization and rapid remediation central.
Recommendation — Prioritise exploited SQL Server instances for immediate remediation and verified closure.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	CVE exploitation directly requires timely remediation and verification of corrective action.
	AU-6 — Audit Review, Analysis, and Reporting	Post-exploitation checks depend on log review to detect suspicious database activity.
	IA-5 — Authenticator Management	Compromised database service accounts and exposed secrets may need rotation after exploitation.
Recommendation — Apply flaw remediation controls to patch or mitigate the vulnerable SQL Server instance quickly. Review SQL Server and host logs for evidence of exploitation before and after remediation. Rotate any service credentials, keys, or tokens that could have been exposed by the flaw.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	KEV status makes exposure identification and prioritization the first practical step.
Recommendation — Identify all exposed SQL Server assets and rank them for urgent response.

Practitioner Guidance

What to prioritise: Triage this as an active-exploitation event, not a normal vulnerability ticket. Confirm whether the instance is internet-facing, business-critical, or running with elevated service account privileges, then shorten the path to remediation accordingly.

What to verify: Check for signs of compromise before or during patching, including unexpected SQL Server child processes, new local accounts, changed scheduled tasks, unusual outbound connections, and unexplained service account activity. If the server handled sensitive workloads, preserve logs and relevant host telemetry before making major changes.

Practitioner takeaway: For a KEV-listed remote code execution flaw in SQL Server, the priority is to remove exploitable exposure and validate compromise status first, because patching alone does not answer whether attackers already used the window.