{"id":7513,"date":"2026-06-09T12:12:25","date_gmt":"2026-06-09T17:12:25","guid":{"rendered":"https:\/\/andreas-wolter.com\/?p=7513"},"modified":"2026-06-11T18:30:33","modified_gmt":"2026-06-11T23:30:33","slug":"2606_sqlserver_security_vulnerability_disclosure","status":"publish","type":"post","link":"https:\/\/andreas-wolter.com\/en\/2606_sqlserver_security_vulnerability_disclosure\/","title":{"rendered":"When SQL Server Security Falls Between Documentation, Disclosure, and Vulnerability"},"content":{"rendered":"\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-m0cxh8ps-7045d4e9045e1dd7b903181565987c16\">\n#top .av-special-heading.av-m0cxh8ps-7045d4e9045e1dd7b903181565987c16{\npadding-bottom:10px;\n}\nbody .av-special-heading.av-m0cxh8ps-7045d4e9045e1dd7b903181565987c16 .av-special-heading-tag .heading-char{\nfont-size:25px;\n}\n.av-special-heading.av-m0cxh8ps-7045d4e9045e1dd7b903181565987c16 .av-subheading{\nfont-size:15px;\n}\n<\/style>\n<div  class='av-special-heading av-m0cxh8ps-7045d4e9045e1dd7b903181565987c16 av-special-heading-h3 blockquote modern-quote  avia-builder-el-0  el_before_av_textblock  avia-builder-el-first '><h3 class='av-special-heading-tag'  itemprop=\"headline\"  >When SQL Server Security Falls Between Documentation, Disclosure, and Vulnerability<\/h3><div class=\"special-heading-border\"><div class=\"special-heading-inner-border\"><\/div><\/div><\/div>\r\n\r\n<section  class='av_textblock_section av-m0cxgkjy-c935304b4106b45214698f40e83a9894 '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-7514\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/06\/MicrosoftCampusRedmondWA-1030x503.jpg\" alt=\"Microsoft campus, Redmond\" width=\"1030\" height=\"503\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/06\/MicrosoftCampusRedmondWA-1030x503.jpg 1030w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/06\/MicrosoftCampusRedmondWA-300x146.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/06\/MicrosoftCampusRedmondWA-768x375.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/06\/MicrosoftCampusRedmondWA-705x344.jpg 705w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/06\/MicrosoftCampusRedmondWA.jpg 1500w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" \/><\/p>\n<p style=\"font-size: 0.9em; color: #666666; line-height: 1.4; text-align: center;\">Microsoft campus, Redmond. Photo by the author.<br \/>\nThe article reflects my personal views on SQL Server security research, documentation, and coordinated disclosure.<\/p>\n<p>The recent public discussion around YellowKey and Microsoft\u2019s vulnerability disclosure process has put vulnerability research, coordinated disclosure, and Microsoft\u2019s Security Response Center (MSRC) into the spotlight.\u00a0 \u00a0While that specific discussion is about Windows and BitLocker, it exposes a broader problem that many researchers recognize: vulnerability disclosure is often framed as a simple responsibility of the researcher.<\/p>\n<p>The idealized workflow is straightforward: find the issue, report it, wait for the vendor, and accept the outcome.<\/p>\n<p>But coordinated disclosure cannot be a one-way obligation.<\/p>\n<p>If researchers are expected to invest serious time, understand the product deeply, document complex behavior, build a reproducible proof of concept, sometimes even create a video, wait for triage, and then live with whatever decision the vendor makes, then the vendor side also has responsibilities.\u00a0 \u00a0That includes product-specific review, clear reasoning, timely communication, and transparent disclosure when security-relevant behavior changes.<\/p>\n<p>To be clear, MSRC does not have an easy role.\u00a0 Microsoft has to evaluate reports across a vast product portfolio, protect customers on a global scale, and avoid releasing information that could increase risk before fixes are broadly available.\u00a0 But that makes product-specific review and clear communication more important, not less.<\/p>\n<p>My own focus is Microsoft SQL Server, Microsoft\u2019s flagship database platform.\u00a0 SQL Server rarely becomes the center of public vulnerability debates, but given the critical role of an RDBMS in enterprise environments, and the recent increase in findings from independent researchers, it is worth looking at how these disclosure challenges appear there as well.<\/p>\n<p>For customers, this is not only a researcher-process issue.\u00a0 SQL Server security depends heavily on documented permission boundaries, role semantics, and servicing behavior.\u00a0 If those change silently, organizations may continue relying on assumptions that are no longer true.\u00a0 In enterprise environments, those assumptions often lead to role assignments, approved exceptions and the base for audit decisions.<\/p>\n<h2>SQL Server issues often do not look like classic vulnerabilities<\/h2>\n<p>Let\u2019s start with this: Many SQL Server security findings do not look like obvious vulnerabilities at first glance.<\/p>\n<p>They are not always remote unauthenticated code execution or missing authorization.<br \/>\nVulnerabilities in SQL Server often involve combinations of permissions, roles, ownership chaining, system stored procedures, SQL Agent and other subsystems.<\/p>\n<p>A generic vulnerability process may look at a finding and conclude:<\/p>\n<p>\u201cRequires role membership.\u00a0 \u201d<br \/>\n\u201cRequires permission X.\u00a0 \u201d<br \/>\n\u201cLooks like documented behavior.\u00a0 \u201d<br \/>\n\u201cLooks like intended behavior.\u00a0 \u201d<\/p>\n<p>But they may still miss the security impact.<\/p>\n<p>In SQL Server, much like in any other system the question is not only which permission is required.\u00a0 It is also what practical power that permission gives the user, how commonly it is assigned, and <u>whether the resulting behavior still matches the boundary customers and administrators reasonably expect<\/u>.<\/p>\n<p>That is not always easy to determine.<\/p>\n<p>For example, SQL Server does not have a built-in method that reliably answers the question: \u201cWhat can this principal practically do if it holds this permission?\u201d<\/p>\n<p style=\"padding-left: 40px;\"><em>The effective allowed actions challenge<\/em><br \/>\nThe reason is that access control in SQL Server is not action-based, it is permission-based.\u00a0 The permission model is deep, old, and highly composable.\u00a0 Hardly anyone has the full model in their head.\u00a0 I believe I know it reasonably well, and still there are situations where the interaction is not obvious until it is tested.<\/p>\n<p>But that is where many interesting SQL Server findings live.<\/p>\n<h2>The researcher\u2019s work<\/h2>\n<p>Before submitting a serious SQL Server report, a researcher typically has to reproduce the behavior across multiple versions, compare CU and GDR levels, isolate the minimum required permission set, and account for configuration differences that affect reproducibility.<\/p>\n<p>That work alone can take many hours or days.<\/p>\n<p>The researcher then has to explain the escalation path, document expected and observed behavior, and provide a proof of concept that is clear enough for review.\u00a0 For SQL Server permission issues, that often means explaining not only what happened, but why the behavior crosses a boundary that customers would reasonably expect to exist.<\/p>\n<h2>The asymmetry in vulnerability handling<\/h2>\n<p>Once a report enters the vendor process, the balance changes.<\/p>\n<p>The vendor controls the case status, severity assessment, and bug-bar interpretation.\u00a0 The vendor decides whether the issue is fixed, documented, deferred, downgraded, or closed.\u00a0 The vendor controls the advisory wording, whether a CVE is issued, whether the researcher is acknowledged, and whether a bounty is paid.<\/p>\n<p>The researcher can provide evidence, answer questions, refine the proof of concept, and argue the security impact.\u00a0 But the final decision usually belongs to the vendor.<\/p>\n<p>That asymmetry is not inherently wrong.\u00a0 Vendors own their products, understand their servicing constraints, and must balance many customer-risk considerations that may not be visible from the outside.\u00a0 But the asymmetry does create a responsibility to explain decisions clearly, especially when a researcher has submitted a detailed, product-specific escalation analysis.<\/p>\n<p>This becomes particularly important when the final outcome is one of the familiar gray-zone conclusions: low severity, does not meet the bar, will be documented, will not be fixed, or no CVE.\u00a0 Some of those outcomes may be correct.\u00a0 Not every report is a vulnerability, and some reports really do describe documented or intended behavior.<\/p>\n<p>The problem starts when the reasoning is too thin to show that the product-specific attack path was understood.\u00a0 For SQL Server, that matters because the impact is often not obvious from the prerequisite permission alone.\u00a0 A finding may require a role or permission, but the relevant question is whether that role or permission was intended to cross the security boundary that the behavior now crosses.<\/p>\n<p>If the explanation does not address that boundary question, researchers are left guessing whether the issue was rejected on its merits or because the impact was not fully understood.\u00a0 Over time, that weakens trust in the process.<\/p>\n<p><strong>\u00a0<\/strong><\/p>\n<h2>SQL Server triage needs SQL Server context<\/h2>\n<p>In my opinion, SQL Server permission issues cannot be reviewed only by looking at the prerequisites.<\/p>\n<p>A meaningful review should also consider:<\/p>\n<ul>\n<li>What can the user do after obtaining this permission or role?<\/li>\n<li>What is the documented intent of the assigned permission and roles?<\/li>\n<li>Would customers reasonably treat it as below sysadmin or db_owner?<\/li>\n<li>Does the behavior cross a boundary that the product or documentation implies should exist?<\/li>\n<li>How would a customer learn about a change of the security model for the task in question?<\/li>\n<\/ul>\n<p>This is also how <strong>Fabiano Amorim<\/strong>, who has reported multiple SQL Server security issues, put the technical challenge this way:<\/p>\n<blockquote><p>\u201cAfter spending time doing SQL Server security research, I have learned that a specific permission or role does not tell the whole story.\u00a0 It is the starting point of the analysis, not the conclusion.\u00a0 The question I ask myself for every feature, prerequisite, or permission is whether it creates a practical attack path across an expected security boundary.\u00a0 SQL Server\u2019s security model is powerful, but compatibility requirements, old features, ownership chaining, system procedures, SQL Agent, impersonation, and trusted execution contexts can interact in unexpected ways.\u00a0 \u201d<\/p><\/blockquote>\n<p>This is important to consider for the documentation as well.\u00a0 A documentation warning can help customers understand risk, but it does not automatically resolve the underlying security question.\u00a0 If a role exists to provide delegated administration below sysadmin, customers will reasonably treat it as a boundary.\u00a0 If that role can become a practical path to sysadmin, the boundary no longer holds.\u00a0 Documenting that risk does not preserve the purpose of the role; it tells customers that the role should not be treated as lower-privileged in any meaningful security sense.<\/p>\n<p><strong>\u00a0<\/strong><\/p>\n<h2>Recent examples: The ##MS_DatabaseManager## role, spatial helper procs<\/h2>\n<p>A recent example is the ##MS_DatabaseManager## role, which turned out to be a direct EoP path to sysadmin: <a href=\"https:\/\/andreas-wolter.com\/en\/2604_sqlserver_privilegeescalation_databasemanager-part2\/\">##MS_DatabaseManager## Privilege Escalation (Part 2): The Ownership-Based Security Model<\/a><\/p>\n<p>The role is not sysadmin.\u00a0 It exists to delegate database-management capabilities without giving full server control.<\/p>\n<p>That is the point of its existence.<\/p>\n<p>But if membership in that role creates a practical path to sysadmin under real conditions, the question is no longer simply whether some broad warning exists somewhere in the documentation.<br \/>\nThe question becomes whether customers can safely treat the role as less privileged than sysadmin in the way the product design and documentation still imply.<\/p>\n<p>If a role exists, someone looking for a role lower than sysadmin will assign it.<\/p>\n<p>Another example is the recent documentation update for the spatial helper system procedures <em>sp_help_spatial_geography_histogram<\/em> and <em>sp_help_spatial_geometry_histogram<\/em>, which now state that membership in the sysadmin fixed server role is required.<\/p>\n<p>According to Fabiano Amorim, who reported the original issue, the procedures already required sysadmin to complete successfully without errors.\u00a0 However, the vulnerable injected code path <u>could still execute before the procedure later failed<\/u>.\u00a0 In other words, sysadmin was required for a clean successful execution of the full procedure, but not for the security-relevant injected code to run.\u00a0 (Read more in my June update to this list: <a href=\"https:\/\/andreas-wolter.com\/en\/least-privilege-sysadmin-required-sql-server\/\">The challenges for least privilege: When sysadmin is still required in Microsoft SQL Server<\/a>)<\/p>\n<p>That distinction is another example why SQL Server findings can be difficult to classify from prerequisites alone.\u00a0 Looking only at the documented requirement may suggest that the procedure is restricted to sysadmins only.\u00a0 But the actual execution path showed that security-relevant injected code could run before the procedure later failed.<\/p>\n<p>Microsoft later updated the documentation to reflect the sysadmin requirement.\u00a0 That may have corrected the documented prerequisite, but it did not make the security relevance obvious to customers.\u00a0 If a system stored procedure involved in a security fix has this kind of execution-path nuance, customers and defenders should not have to reconstruct the meaning of the change from documentation diffs, blog posts, and post-fix behavior.<\/p>\n<p>If a system stored procedure was hardened because it could be abused, the release notes and documentation should make the security relevance clear enough for customers to act.\u00a0 For security relevant changes we have CVEs.\u00a0 No such notification channel was used here.\u00a0 The KB entry only stated generically that the vulnerability was fixed.<\/p>\n<h2>Documentation is a core component of the security model<\/h2>\n<p>For complex products, documentation is not just a manual.\u00a0 It is part of the security model.<\/p>\n<p>It may explicitly draw the line between what security controls the vendor handles and what configuration security the buyer must implement.\u00a0 It serves as the source of truth for threat modeling.<\/p>\n<p>DBAs, architects, auditors, consultants, and security teams use documentation to decide what is safe to delegate.\u00a0 It is used to define least privilege.\u00a0 To justify role assignments.\u00a0 And to evaluate whether a finding is expected, acceptable, or a violation of policy.<\/p>\n<p>If documentation says or implies that a role is suitable for a delegated task, customers will use it that way.<\/p>\n<h2>Silent documentation changes<\/h2>\n<p>That is why silent documentation changes are a problem.<\/p>\n<p>If Microsoft changes documentation to say that a role can potentially elevate privileges, that may be useful for future readers.\u00a0 But unless there is a CVE, a release-note entry, or another official announcement, many customers will never know that the security expectation has changed.<\/p>\n<p>The same applies when system procedures suddenly require higher privileges, or when a formerly available path is quietly closed.\u00a0 Without a clear announcement, customers may not realize that the permission model they relied on has changed, or that an existing role assignment now carries a different risk than they previously understood.<\/p>\n<p>For researchers, there is another issue.\u00a0 If behavior changes silently, or if release notes do not clearly connect the fix to the reported issue, it becomes difficult to understand whether the change was the result of one\u2019s report or whether a different issue was independently found.\u00a0 That affects trust in the process.<\/p>\n<p>At the same time, I understand that a vendor has to consider risks that may not be visible to the researcher.\u00a0 A vulnerability may point to related weaknesses with even greater impact.\u00a0 If too much information is disclosed before customers have had a realistic opportunity to patch, the consequences can extend beyond individual customers and become a national-level risk.\u00a0 That is why vendors often operate under a \u201cminimum necessary disclosure\u201d policy.<\/p>\n<p>The difficult part is finding the right balance.\u00a0 Responsible disclosure should not require full public details on day one, but it does require enough clarity for researchers and customers to understand what changed, why it matters, and whether their own security assumptions need to be revisited.<\/p>\n<h2>Coordinated disclosure goes both ways<\/h2>\n<p>Security researchers are often told to report issues responsibly.<\/p>\n<p>That is fair.\u00a0 Researchers should not ignore customer risk.\u00a0 Publishing exploit details before customers have a reasonable way to protect themselves can cause harm.<\/p>\n<p>But disclosure is not only something researchers do.<\/p>\n<p>Vendors also disclose, or choose not to disclose.<\/p>\n<p>When Microsoft silently changes documentation, changes privilege requirements, closes an escalation path, or hardens system procedures without a clear security note, that is also a disclosure decision.<\/p>\n<p>Customers may not know that anything security-relevant changed.\u00a0 Researchers may not know whether their report was understood.\u00a0 Other defenders may continue operating under old assumptions.<\/p>\n<p>Coordinated disclosure should not only mean that researchers coordinate with the vendor.<\/p>\n<p>It should also mean that vendors communicate security-relevant changes clearly enough for customers and defenders to act.<\/p>\n<h2>What would help<\/h2>\n<p>In my opinion, for SQL Server specifically, several things would improve the process.<\/p>\n<ul>\n<li>Severity evaluation should consider the expected behavior of a permission or role. If a documented role can become sysadmin, the starting point should not automatically define the issue low impact.<\/li>\n<li>Documentation and servicing should be aligned. If a role or permission combination is not intended to be a security boundary, say that clearly.\u00a0 Contained Availability Groups are a good example where the documentation explicitly calls out that they are not a security boundary.<\/li>\n<li>If a role or permission combination is intended to be a security boundary, then escalation paths across that boundary should be treated accordingly.<\/li>\n<li>Release notes should make security-relevant behavior changes easier to map. Customers and researchers should not have to reverse-engineer whether a CU or GDR fixed a reported issue, a related issue, or only one visible symptom.<\/li>\n<li>Closure decisions should include enough reasoning to be useful. A simple \u201cDoes not meet the bar\u201d may be administratively efficient, but it does little to maintain trust when the researcher submitted a detailed, product-specific escalation analysis.<\/li>\n<\/ul>\n<p>None of this requires treating every report as critical.<\/p>\n<p>It requires treating SQL Server security research as SQL Server security research.<\/p>\n<h2>Why this matters beyond researchers<\/h2>\n<p>This may sound like a researcher-process issue, but it is ultimately also a customer issue.<\/p>\n<p>Customers depend on vendors to evaluate security reports correctly.\u00a0 They depend on CVEs, advisories, release notes, documentation, and servicing decisions to understand their exposure.<\/p>\n<p><strong>Emad Al-Mousa<\/strong>, a security researcher who has reported findings across major database platforms including SQL Server and Oracle, made a similar point from the customer-impact side:<\/p>\n<blockquote><p>\u201cExternal researchers should be treated as real partners, especially when they spend time analyzing a critical product such as SQL Server.\u00a0 Findings that are classified as low impact can still represent real security concerns for customers, particularly when they affect visibility, auditing, or the protection of sensitive data.\u00a0 When those issues are dismissed without sufficient explanation or documentation updates, customers may never understand the risk.\u00a0 \u201d<\/p><\/blockquote>\n<p>If permission changes are buried in documentation without a notification process, customers have little chance to realize that the burden has shifted to them.<\/p>\n<p>If researchers lose trust in the reporting process, some issues may be disclosed less responsibly, sold elsewhere, or never reported at all.<\/p>\n<p>None of those outcomes is good for defenders.<\/p>\n<h2>Final thought<\/h2>\n<p>Researchers should be expected to act responsibly.\u00a0 Vendors should also be expected to handle responsible research with enough depth, transparency, and product knowledge to make the process worth trusting.<\/p>\n<p>Coordinated disclosure should protect customers.\u00a0 To do that, it must respect both sides of the process: the work required to find and explain issues, and the customer need to understand when security assumptions have changed.<\/p>\n<p>Stay secure<br \/>\nAndreas<\/p>\n<\/div><\/section>\r\n\r\n<div  class='flex_column av-vb4k9-5c390a090b8757fafe36b077b8d164ce av_one_full  avia-builder-el-2  el_after_av_textblock  el_before_av_social_share  first flex_column_div  column-top-margin'     ><div  class='hr av-7coejt-c2ec2e6fb5dfa2080806798514392349 hr-default  avia-builder-el-3  el_before_av_textblock  avia-builder-el-first '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\n<section  class='av_textblock_section av-6e2h5l-f15ae97e4272ea5736cfded1578c506a '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><p><b data-path-to-node=\"13,0\" data-index-in-node=\"0\">Are hidden vulnerabilities like this exposing your data?<br \/>\n<\/b>Standard audits often miss the complex privilege escalation paths discussed above. As a former Microsoft Security PM, I identify the foundational vulnerabilities and lateral movement risks that generic scripts ignore. I now offer my proprietary SQL Server Security Assessments exclusively through my company, Sarpedon Quality Lab LLC.<\/p>\n<\/div><\/section>\n<div  class='avia-button-wrap av-4g244p-d3cf5f2fd6f8d204a668e59438bbe08a-wrap avia-button-center  avia-builder-el-5  el_after_av_textblock  el_before_av_hr '>\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-4g244p-d3cf5f2fd6f8d204a668e59438bbe08a\">\n#top #wrap_all .avia-button.av-4g244p-d3cf5f2fd6f8d204a668e59438bbe08a{\nfont-size:14px;\nbackground-color:#75a823;\nborder-color:#75a823;\ncolor:#ffffff;\nbox-shadow: 0 0 5px 5px ;\ntransition:all 0.4s ease-in-out;\n}\n<\/style>\n<a href=\"https:\/\/sarpedonqualitylab.us\/sql-server-security-assessment\/\" class=\"avia-button av-4g244p-d3cf5f2fd6f8d204a668e59438bbe08a avia-icon_select-yes-left-icon avia-size-medium avia-position-center\" target=\"_blank\" rel=\"noopener\"><span class='avia_button_icon avia_button_icon_left' aria-hidden='true' data-av_icon='\ue832' data-av_iconfont='entypo-fontello'><\/span><span class='avia_iconbox_title' >View Security Assessment Tiers at Sarpedon Quality Lab<\/span><\/a><\/div>\n<div  class='hr av-2df7qh-97a70af29223f51de4e8a5134ac96e31 hr-default  avia-builder-el-6  el_after_av_button  avia-builder-el-last '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div><\/div><div  class='av-social-sharing-box av-5n5vpa-78ffdd9d224b4a246af65bdc00dce900 av-social-sharing-box-default  avia-builder-el-7  el_after_av_one_full  el_before_av_hr  av-social-sharing-box-fullwidth'><div class=\"av-share-box\"><h5 class='av-share-link-description av-no-toc '>Share article<\/h5><ul class=\"av-share-box-list noLightbox\"><li class='av-share-link av-social-link-facebook' ><a target=\"_blank\" aria-label=\"Share on Facebook\" href=\"https:\/\/www.facebook.com\/sharer.php?u=https:\/\/andreas-wolter.com\/en\/2606_sqlserver_security_vulnerability_disclosure\/&amp;t=When%20SQL%20Server%20Security%20Falls%20Between%20Documentation%2C%20Disclosure%2C%20and%20Vulnerability\" aria-hidden=\"false\" data-av_icon=\"\ue8f3\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Facebook\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Facebook<\/span><\/a><\/li><li class='av-share-link av-social-link-twitter' ><a target=\"_blank\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=When%20SQL%20Server%20Security%20Falls%20Between%20Documentation%2C%20Disclosure%2C%20and%20Vulnerability&amp;url=https:\/\/andreas-wolter.com\/en\/?p=7513\" aria-hidden=\"false\" data-av_icon=\"\ue8f1\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Twitter\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Twitter<\/span><\/a><\/li><li class='av-share-link av-social-link-linkedin' ><a target=\"_blank\" aria-label=\"Share on LinkedIn\" href=\"https:\/\/linkedin.com\/shareArticle?mini=true&amp;title=When%20SQL%20Server%20Security%20Falls%20Between%20Documentation%2C%20Disclosure%2C%20and%20Vulnerability&amp;url=https:\/\/andreas-wolter.com\/en\/2606_sqlserver_security_vulnerability_disclosure\/\" aria-hidden=\"false\" data-av_icon=\"\ue8fc\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on LinkedIn\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on LinkedIn<\/span><\/a><\/li><\/ul><\/div><\/div>\r\n\r\n\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-4ofg9q-c2108540b480aba02923089240a3a176\">\n#top .hr.hr-invisible.av-4ofg9q-c2108540b480aba02923089240a3a176{\nheight:50px;\n}\n<\/style>\n<div  class='hr av-4ofg9q-c2108540b480aba02923089240a3a176 hr-invisible  avia-builder-el-8  el_after_av_social_share  el_before_av_comments_list '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\r\n\r\n<div  class='av-buildercomment av-284ftq-f5a1564cd6b8ffad6ce835e2d40de4b7  av-blog-meta-author-disabled av-blog-meta-html-info-disabled'><\/div>","protected":false},"excerpt":{"rendered":"","protected":false},"author":4,"featured_media":7514,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[57],"tags":[206],"class_list":["post-7513","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-en","tag-sql-security"],"_links":{"self":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/7513","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/comments?post=7513"}],"version-history":[{"count":8,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/7513\/revisions"}],"predecessor-version":[{"id":7526,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/7513\/revisions\/7526"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media\/7514"}],"wp:attachment":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media?parent=7513"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/categories?post=7513"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/tags?post=7513"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}