CVE-2019-1068 was published in July 2019 and patched the same month; CISA added it to the Known Exploited Vulnerabilities catalog on 26 August 2026 with a 29 August due date, and it needs a privileged SQL login to work.
What happened
On 26 August 2026, CISA added CVE-2019-1068 to the Known Exploited Vulnerabilities catalog under the name “Microsoft SQL Server Remote Code Execution Vulnerability.” NVD’s republication of the entry gives a cisaExploitAdd of 2026-08-26 and a cisaActionDue of 2026-08-29. That is tomorrow, and it is a Saturday.
The vulnerability itself is seven years old. NVD shows it published 15 July 2019, the record last modified 27 August 2026. Microsoft’s description, carried in the CVE record: “A remote code execution vulnerability exists in Microsoft SQL Server when it incorrectly handles processing of internal functions, aka ‘Microsoft SQL Server Remote Code Execution Vulnerability’.” It carries a CVSS v3.1 base score of 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
The PR:L in that vector is the whole character of the bug, and it is the part most likely to be lost in a headline. This is not an unauthenticated remote code execution flaw. It requires privileges — a low-privileged login on the SQL Server instance is enough, but something is required. An attacker who has one can get code execution in the context of the database engine.
Microsoft fixed it in the July 2019 security updates. KB4505217, which Microsoft’s own support article describes as the security update for SQL Server 2014 Service Pack 2 GDR released 9 July 2019, takes the affected components to build 12.0.5223.6 and supersedes KB4057120. It was one of a set of updates issued that month across the then-supported SQL Server branches.
CISA’s catalog entry gives no account of how the vulnerability is being exploited, by whom, or against what. Its required action is the same boilerplate string that appears on every entry in this week’s additions, including the ones on 14-day clocks. Microsoft’s Security Update Guide page for the CVE is a JavaScript application that returns nothing to automated retrieval, and the July 2019 CVRF bulletin lists the CVE without per-product detail. Secondary coverage reports that the catalog marks the vulnerability as not known to be used in ransomware campaigns; we could not read that field, because cisa.gov blocks automated fetching.
Why it matters
Start with what PR:L does to the threat model. A perimeter-facing, unauthenticated RCE in a database engine would be an emergency in the ordinary sense: anyone who can reach port 1433 owns the box. This is not that. To use CVE-2019-1068 an attacker needs a login. That places it firmly in the post-compromise half of an intrusion — the stage after credential theft, after a phished service account, after an application’s connection string turned up in a repository or a config file. It is a privilege and execution primitive for someone already inside, not a way in.
That is worth saying plainly because it changes who should care and how much. If your SQL Servers are unreachable from the internet, this does not become a non-issue; it becomes an issue about credential hygiene and lateral movement rather than about exposure. The realistic attack path is an attacker with a stolen application login using a seven-year-old bug to jump from “can query one database” to “can run code as the SQL Server service account.” What that account can reach next is the actual blast radius, and in a lot of environments the answer is uncomfortable, because SQL Server service accounts accumulate rights the way old file shares accumulate permissions.
The second thing worth noticing is which instances are still affected. A seven-year-old flaw fixed in a cumulative update is, by construction, absent from any SQL Server that has been taking updates. The population that remains vulnerable is not the well-maintained estate. It is the instances that stopped receiving updates for structural reasons: SQL Server Express bundled inside a third-party product, database engines embedded in appliances, application databases where the vendor pins a supported build and voids support if you patch past it. These are the instances that do not appear in the patch report because they do not appear in the inventory, and they are the ones where “just apply the update” runs into a support contract.
Third, look at the shape of this week’s additions. Of the six CVEs CISA added on 26 August, five predate 2023: two from 2015, this one from 2019, one from 2021, one from 2022. Only the Citrix NetScaler flaw is current. CISA is backfilling the catalog with old vulnerabilities for which it has newly acquired exploitation evidence, and a backfilled entry does not arrive as history. It arrives with a live federal deadline attached. An agency that closed its 2019 remediation tickets years ago is being asked to reopen the question in three days, against an asset population that has drifted for seven.
Finally, the clock. CVE-2019-1068 sits in the three-day band; the Citrix flaw added the same day shares its 29 August date; the ownCloud flaw added a day later is due 30 August. Meanwhile a CVSS 9.8 deserialization bug and a Linux kernel out-of-bounds write from the same 26 August batch got 14 days. Under BOD 26-04 that divergence is expected — deadlines derive from internet exposure, KEV listing, exploit automation, and whether technical impact is total or partial, not from severity. But the entry does not say which of those applied here, and the authoritative schedule is published only as images that public transcriptions disagree about. So an agency knows the date is Saturday and does not know, from the record, what else the date carries with it.
What to do
Inventory by build number, not by patch status. The question is not whether an instance is “patched.” It is which build it is on. Any SQL Server running a build that predates the July 2019 updates is in scope. For SQL Server 2014 SP2, KB4505217 takes the engine and Analysis Services to 12.0.5223.6; instances below that are unfixed. Query SELECT @@VERSION and SERVERPROPERTY('ProductVersion') across the estate rather than trusting a patch-management dashboard that may not enumerate SQL components separately.
Go looking for the instances nobody owns. Scan for SQL Server Express and embedded engines shipped inside other software — monitoring tools, backup products, line-of-business applications, appliance firmware. These are the ones most likely to be sitting on a 2019-era build, and they will not be in the database team’s inventory because the database team did not install them.
Treat the logins as part of the remediation. Because exploitation requires a login, credential hygiene is a real control here and not a consolation prize. Enumerate logins on affected instances, remove orphaned and shared accounts, revoke rights that applications no longer use, and check whether any application connects with elevated privileges it does not need.
Check what the service account can reach. A SQL Server engine running as LocalSystem or as a domain account with broad rights turns a database-scoped bug into a domain-scoped one. Where the engine runs with more than it needs, that is worth fixing regardless of this CVE’s deadline.
Where a vendor pins the build, isolate instead. If an ISV support agreement blocks the update, restrict network reachability to the instance and tighten authentication to it. The vector is AV:N, so reducing who can open a connection is a genuine mitigation, not a gesture. Document the decision — under BOD 26-04 the fallback for an unfixable asset is formal, and “the vendor would not let us” needs to be written down somewhere before Saturday, not after.
Sourcing note
KEV dates, the vulnerability name, the required-action text, the CVSS score and vector, the publication and last-modified dates and the description come from NVD’s API record for CVE-2019-1068, which republishes CISA’s catalog fields verbatim. cisa.gov returns 403 to automated fetching and blocked a direct request for the 26 August alert page, so the catalog page was not read and the catalog’s ransomware-use field could not be checked; the report that it is marked not known to be used in ransomware campaigns is secondary and is reported here as such.
Build and KB details for SQL Server 2014 SP2 come from Microsoft’s own support article for KB4505217. Microsoft’s Security Update Guide page for CVE-2019-1068 requires JavaScript and returned no vulnerability content to automated retrieval, and the July 2019 CVRF bulletin lists the CVE without per-product remediation detail, so a complete list of affected SQL Server versions and their fixed builds was not established from a Microsoft primary source. Tenable’s Nessus plugin 126631 for the July 2019 SQL Server updates enumerates ten KB articles — 4505217, 4505218, 4505219, 4505220, 4505221, 4505222, 4505224, 4505225, 4505419 and 4505422 — but that is a scanner vendor’s list, not Microsoft’s, and the mapping of each KB to a version and build was not verified here.
No public account of the exploitation exists that we could find. CISA cites no evidence in the entry, no vendor has published telemetry, and no named victim has been reported. The interpretation of PR:L and its consequences is analysis, not vendor statement. Deadline-band comparisons come from the NVD records for the other CVEs in the same additions. Unresolved: what exploitation CISA is acting on, and which SQL Server branches beyond 2014 SP2 remain affected at builds still in production.
Leave a Reply