Press "Enter" to skip to content

Day: September 18, 2026

Sysadmins Bypassing Disabled xp_cmdshell

Fabiano Amorim explains a vulnerability:

SQL injection inside Microsoft-signed system stored procedures is not supposed to happen. Yet, as I’ve been documenting in this series, it happens more often than you may assume.

This article walks through another one I found and reported to the Microsoft Security Response Center (MSRC). It’s a textbook SQL injection sitting inside sys.sp_MSdeletefoldercontents, a system stored procedure used by SQL Server replication.

What makes it interesting is not the injection technique itself (there is no clever Unicode trick this time), but what it enables: a working execution path for xp_cmdshell on a server where xp_cmdshell is explicitly disabled by configuration.

Admittedly, I kind of shrug my shoulders at this one as well. You already need to be sysadmin, and sysadmins can enable xp_cmdshell whenever. I understand that the point of Fabiano’s post is that the procedure call ignores xp_cmdshell’s status, so there’s something to it. But I have trouble thinking that the SQL Server team made the wrong call in deciding it’s a low-risk vulnerability.

Leave a Comment

Comparing xp_readerrorlog and sp_readerrorlog

Steve Jones looks at a pair of procedures:


I was creating a question on sp_readerrorlog and realized that this procedure is different from the one it wraps: xp_readerrorlog. This post digs into a few differences.

Click through for the answer, though Steve’s reference of sp_readerrorlog being “new” is, I think, not quite right. I’m pretty sure that both sp_readerrorlog and xp_readerrorlog were introduced in SQL Server 2005. I did dig up a Rodney Landrum article from April of 2010 talking about sp_readerrorlog, so it was at least in SQL Server 2008.

Leave a Comment

A Bug in a Frameless Window Aggregate

Hugo Kornelis digs into an execution plan:

The OVER clause, that can be added to aggregate functions to turn them into window aggregates, can come with or without a frame specification, in the form of an ORDER BY clause, plus an explicit or implied ROWS or RANGE clause. If there is no frame specification, then every row in a partition, or window, can see all other rows in the same partition or window for the purpose of the aggregation.

In plansplaining part 6, I looked at this specific form of window aggregation, and explained in detail all the steps that the execution plan takes to compute the aggregation result and add it to each of the rows, for every row in each window.

Click through for another look at the plan.

Leave a Comment

The Case for Foreign Key Constraints

Greg Low violates Betteridge’s Law of Headlines:

Foreign keys are used to ensure referential integrity in relational databases. We don’t want to have orders for customers that don’t exist, or have lines on the orders that refer to products that don’t exist. That seems straightforward enough – and a good idea – so why is there an endless discussion in the development community about whether databases should include declared foreign key constraints or not?

I tend to be a foreign key extremist, in that I want key constraints whenever possible. There are certain specific cases in which foreign key constraints can’t work, but I’d argue they’re much rarer than people think.

Leave a Comment

Connection Recency in Fabric REST APIs

Ryan Adams explains a concept:

Connections are shared infrastructure in Microsoft Fabric. Pipelines, dataflows, semantic models, and other Fabric items use them to reach data sources without storing connection details and credentials in every item. Connection Recency adds the context administrators need to understand how each connection is being used. If you go to “Manage Connections and Gateways” in Fabric settings and open the settings of any connection, the following information card will populate:

Click through to learn more about connection recency and how it can be helpful to understand the mechanic.

Leave a Comment

Delays on Postgres 19

Elizabeth Garrett Christensen digs into some details:

Postgres 19 won’t make the expected release date. PostgreSQL has shipped its major version every fall for the last several years. But this year, the code is in a heavy review cycle, major features have been reverted during beta, and many others are under heavy revision. Beta 4 is scheduled for Sept. 24, 2026. A release of Postgres 19 is certainly delayed by weeks and maybe even months.

Postgres 19 was an ambitious release already, with a lot of large features. With any project, you have to choose priorities. For Postgres, the priorities were quality, followed by shipping within the time window. The team is reducing the scope of the release to get closer to meeting its timeline with the quality it requires.

We can see that Postgres 19 is a rather ambitious release, and Elizabeth includes a list of things that might not make it immediately.

Christophe Pettus also provides some historical context:

PostgreSQL 18 had its first release candidate on September 4, 2025, and went GA three weeks later. As I write this, on September 14, 2026, PostgreSQL 19 has no release candidate date. It has a fourth beta scheduled for September 24, a commit freeze for that beta on September 19, and a stated goal of GA “by the end of October.” In the last three weeks it has lost two of the features that headlined every “what’s new in 19” post written since June, including mine. On August 31, Bruce Momjian wrote on -hackers that “it feels we are in an unprecedented situation here.” A week later, Joshua Drake proposed moving the release to spring 2027. Nobody took him up on it. Nobody laughed, either.

This is not a “PostgreSQL is falling apart” post. The project reverts things late every year; the PostgreSQL 11 cycle had a scariest-patch tournament of its own, and WAIT FOR took a decade and three reverts to land. But 19 is different in degree.

Leave a Comment