You Don't Wait for Something to Look Dangerous Before You Take It Seriously

Wed, 02 Sep 2026 15:44:33 +0000

You don't wait for something to look dangerous before you take it seriously. You take it seriously because someone qualified already has.

That's a small idea with a lot riding on it. Most of the costly mistakes we see in IT and security don't happen because nobody knew about a risk. They happen because the risk didn't look urgent yet, so it sat at the bottom of a list until it did.

Visible danger is a lagging signal

By the time a risk is obvious to everyone in a room, it's usually already been a risk for a while. Obvious is late. The people who actually understand a system, a contract, or a process can typically see a problem taking shape long before it's loud enough for everyone else to notice from the outside.

That gap, between when a real risk starts and when it becomes visible to a non-specialist, is exactly where the damage happens. Waiting for the visible version of a problem before acting on it isn't caution, it's just later.

What "qualified" is actually for

A good partner isn't the one who reacts fastest once something's on fire. It's the one who was already watching, who flagged the issue before it needed flagging urgently, and who already had a plan in place before you needed one.

That's a genuinely different skill from incident response. It's not about being fast when things go wrong. It's about noticing quietly, consistently, before things go wrong, and being trusted enough that "this needs attention" is taken seriously the first time it's said, not the third.

A recent example

A few weeks ago, we flagged a SharePoint vulnerability scoring 9.8 out of 10, CVE-2026-20963, before most organisations running it had any real reason to think about it. It wasn't an old, deprecated version being targeted either. It affected every supported on-premises SharePoint version at once: Subscription Edition, 2019, and 2016.

Microsoft shipped a patch for it in January 2026. For two months, that patch just sat there, available, unremarkable, one line in a long list of monthly updates. Then on 18 March, the U.S. Cybersecurity and Infrastructure Security Agency added it to their Known Exploited Vulnerabilities catalog, confirming that attackers were actively using it against real environments.

Here's the part worth sitting with: nothing about the vulnerability changed between January and March. The danger was exactly as real in January as it was in March. The only thing that changed was that by March, it was finally visible enough to make headlines.

Acting on it in January meant taking it seriously before it looked dangerous. Acting on it in March meant taking it seriously once everyone else already had to.

Why this matters beyond one CVE

This pattern isn't specific to SharePoint, or to security. It shows up anywhere risk quietly builds before it's acknowledged: a contract clause nobody double-checked, a permission structure that's grown looser over years, a process that's one departure away from breaking. In every case, the actual danger and the visible danger arrive at different times, and the gap between them is where a good partner earns their keep.

The standard worth holding any technology or security partner to isn't "how quickly do you respond when something breaks." It's "what have you already flagged that hasn't broken yet."

Want a partner who's watching before things get loud? Get in touch and we'll show you what we're already keeping an eye on.

Get in Touch

SharePoint CVE-2020-1147

Tue, 21 Jul 2020 11:12:36 +0000

SharePoint CVE-2020-1147 now has a PoC

Microsoft has released a patch to fix CVE-2020-1147 which they have described as following.

“A remote code execution vulnerability exists in .NET Framework, Microsoft SharePoint, and Visual Studio when the software fails to check the source markup of XML file input. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the process responsible for deserialization of the XML content.

To exploit this vulnerability, an attacker could upload a specially crafted document to a server utilizing an affected product to process content.”

Basically, low privileged user who knows what they are doing can get remote code execution on the SharePoint server. Technically you don’t even need SharePoint running as it affects .Net applications, so it’s a pretty big issue.

The bug was discovered by Oleksandr Mirosh, Markus Wulftange and Jonathan Birch and you can check out the PoC if you really want to understand more.

I would recommend that everyone gets to patching ASAP as this could be used for lateral movement and privilege escalation to gain domain control.

If your business has an A Team Support agreement you have already been patched.