IT security vulnerability: what it is, how attackers exploit it, and what your business can do

The essentials in 30 seconds

An IT security vulnerability is a flaw in software, hardware or configuration that lets an attacker do something the system was never meant to allow. Here is the uncomfortable truth: the overwhelming majority of successful attacks rely on known vulnerabilities for which a fix had already been available, in some cases for months.

The clearest proof is WannaCry in 2017. The ransomware paralyzed over 200,000 computers in around 150 countries, hit hospitals in the UK and put ransom notes on departure boards of Deutsche Bahn. The patch that would have stopped it had been available for roughly two months before the outbreak.

This article explains what a security vulnerability actually is, how flaws come into existence, how attackers industrialize their exploitation, and, most importantly, what you as a small or medium business can realistically do about it. No fear-mongering, just the mechanics and the countermeasures.

What is an IT security vulnerability?

A security vulnerability (often just “vulnerability” or “security flaw”) is any weakness that allows an attacker to violate the intended security guarantees of a system: to read data they should not see, change data they should not touch, execute code they should not run, or disrupt a service others depend on.

Three points are worth understanding, because they shape everything that follows:

1. Vulnerabilities are normal. All non-trivial software contains errors, and some errors have security consequences. A vulnerability in your stack is not a sign that your vendor is incompetent or that your IT team failed. What matters is what happens after a flaw becomes known.

2. Vulnerabilities are public. Known flaws are catalogued in the CVE system (Common Vulnerabilities and Exposures), each with a unique identifier such as CVE-2021-44228. This transparency is deliberate and useful, but it has a flip side: the moment a vulnerability is published, defenders and attackers learn about it at the same time. From that point, a race begins.

3. Exploitation is industrialized. Nobody sits in a dark room picking your company as a target. Automated scanners sweep the entire internet for systems with known flaws, around the clock. If your server exposes a vulnerable service, it will be found, not because you are interesting, but because you are reachable. We described what that looks like from the victim’s side in our case study anatomy of a server takeover: over 26,000 automated attack attempts against one single weak point.

How do vulnerabilities come into existence?

Roughly three routes, and the third one causes by far the most real-world damage:

Programming errors

Classic software bugs with security impact: a missing length check leads to a buffer overflow, unfiltered user input ends up in a database query (SQL injection) or in a command line (command injection). These flaws are born in development and often lie dormant for years until someone, researcher or attacker, notices them.

Misconfiguration

The software is fine, the setup is not. An administration interface reachable from the internet, a database without a password, an application running with full system privileges, a test account that was never deleted. Misconfiguration is particularly common in smaller companies, because systems are often set up once (“it works now”) and then never revisited.

Outdated software

This is the big one. A flaw becomes known, the vendor releases a patch, and the patch simply never gets installed. From that moment on, the vulnerability is no longer a hidden defect but a documented, publicly known entry point with, in many cases, ready-made exploit code circulating freely. Every day without the patch widens the gap between what attackers know and what your systems can withstand.

Keep this third category in mind. It is the thread that runs through every example below.

WannaCry 2017: the patch existed, the disaster came anyway

If you only remember one story about security vulnerabilities, make it this one.

In May 2017, the WannaCry ransomware spread across the globe within hours. It encrypted the data of infected Windows machines and demanded ransom in Bitcoin. The scale was unlike anything before it: over 200,000 systems in around 150 countries. In the UK, the National Health Service was hit so badly that hospitals had to cancel operations and turn away patients. In Germany, the attack became visible to everyone when departure boards of Deutsche Bahn displayed the ransom screen instead of train schedules.

Technically, WannaCry exploited a vulnerability called EternalBlue in SMBv1, an old version of the Windows file-sharing protocol. Microsoft had catalogued the flaw under the identifier MS17-010.

And here is the point that makes WannaCry the textbook case: Microsoft had published the patch on 14 March 2017, roughly two months before the outbreak. Every organization that had installed this update in time was protected. WannaCry raced almost exclusively through systems that were missing the patch, many of them older machines running Windows 7 or even Windows XP with SMBv1 still switched on.

One more detail deserves attention: the epidemic came to an end without the victims’ defenses playing any part in it. A security researcher stumbled upon a “kill switch”, a domain name embedded in the malware, registered it out of curiosity, and the spread stopped. That was luck, and luck tends to run out.

The lesson for small and medium businesses

The flaw was known, the patch was available, the warnings had been public for weeks. What failed in 2017 was execution, and that is exactly where SMEs are most exposed:

• “It runs, don’t touch it” as the unofficial operations policy
• no defined patch process, updates happen “when there is time”
• old systems kept alive because one legacy application depends on them
• unnecessary services (like SMBv1) left enabled because nobody ever asked whether they are needed

None of these problems require a security genius to fix. What they do require is a named person who owns the task and a routine that makes sure it actually happens, month after month, which is rather less glamorous than it sounds.

Log4Shell 2021: the vulnerability you did not know you had

WannaCry teaches “install your patches”. Log4Shell teaches something subtler: you can only patch what you know you are running.

In December 2021, a critical flaw (CVE-2021-44228) was discovered in Log4j, a Java logging library. A logging library is a tiny helper component that writes event records, the kind of building block developers include without a second thought. The flaw allowed attackers to execute arbitrary code on a server remotely (remote code execution) just by getting a specially crafted string into any input that the application logged, a search field, a user name, a request header.

The severity was one thing. The real shock was the reach. Log4j was embedded in thousands of commercial and internal applications, often several layers deep: your company uses product A, product A includes framework B, framework B ships with Log4j. Countless organizations spent the first days of the crisis not fixing the flaw, but trying to figure out whether and where they were even affected. Many did not know they used Log4j at all, because they had never consciously chosen it.

The lesson: modern software is assembled from components, and every component can carry vulnerabilities into your business. Without an inventory of your systems and, ideally, a software bill of materials (SBOM) for critical applications, you are defending blind against something you have no way of locating.

MOVEit 2023: one flaw, hundreds of victims at once

A third, briefer example shows how professional the exploitation business has become. In 2023, the Clop ransomware group exploited a SQL injection vulnerability (CVE-2023-34362) in MOVEit Transfer, a managed file transfer product used by companies and public agencies to exchange sensitive files. Because so many organizations ran the same product, one single vulnerability turned into a mass data-theft campaign affecting a very large number of organizations and, through them, millions of individuals.

The pattern to note: attackers increasingly target widely deployed products and suppliers, because one working exploit then scales across every customer. You may be affected by a vulnerability in software you use, run by a service provider you pay, without any flaw in your own systems.

The three cases at a glance

Incident (year)	Type of vulnerability	Patch available?	Key lesson
WannaCry (2017)	Flaw in the SMBv1 file-sharing protocol (MS17-010)	Yes, for two months	Install security patches promptly and on a defined schedule
Log4Shell (2021)	Flaw in Log4j, a component embedded almost everywhere (CVE-2021-44228)	Yes, but many could not tell whether they were affected	Keep an inventory down to component level: you can only patch what you know you run
MOVEit (2023)	SQL injection in the MOVEit Transfer file transfer product (CVE-2023-34362)	Yes, though it was often exploited at service providers	Account for supply chain and third-party risk

The race between patch and exploit

Put the three cases side by side and a common mechanic emerges. The life of a security vulnerability follows a timeline:

1. The flaw exists, unknown, sometimes for years.
2. The flaw is discovered, by a researcher, the vendor, or an attacker.
3. A patch is published, usually together with the public advisory.
4. Exploits appear, often within days, sometimes within hours, because attackers analyze the patch to work out exactly what it fixes.
5. Mass scanning begins, automated tools sweep the internet for unpatched systems.

Everything between step 3 and the moment you install the patch is your window of exposure. In 2017, two months were enough for a global catastrophe. As of 2026, the window between patch release and mass exploitation is often measured in days. The uncomfortable conclusion for any business: “we will update during the next maintenance window in three months” is a risk decision, whether you frame it that way or not.

How such an open flaw becomes a concrete cyber attack on a company, and what counts in the first hours once it does, is something our practical guide walks through step by step. A word on zero-days, because the term dominates headlines: a zero-day is a flaw that is exploited before any patch exists, so defenders have had zero days to respond. Zero-days are real, but rare and expensive, and mostly used against high-value targets. For the vast majority of companies, the realistic threat wears a far duller face: a known flaw with an available patch that nobody ever applied. Headlines do little with that, and it happens to be good news for you, since the most effective defense stays entirely within your control.

What your business can actually do

The good news deserves repeating: defending against the most common attack path does not require a security operations center or an enterprise budget. It requires a handful of disciplines, done consistently.

1. Keep an inventory

You cannot patch what you do not know exists. Maintain a current list of your systems: servers, applications, network devices, cloud services, including versions and who is responsible for each. Log4Shell showed why this matters: the companies that coped best were the ones that could answer “where do we run Log4j?” within hours instead of weeks. For your most critical applications, ask vendors which components they embed.

2. Establish a real patch process

Replace “we update when there is time” with a defined routine: security updates for critical, internet-facing systems within days, everything else on a fixed schedule, with a named person responsible and a way to verify it happened. Prioritize by exposure: a vulnerability in a server reachable from the internet is urgent, the same flaw on an isolated internal machine is less so. If you cannot staff this internally, this is one of the most sensible things to outsource, in a managed hosting setup, patching and monitoring of the platform are part of the service instead of a task that competes with your day job.

3. Retire what you do not need

Every service, every open port, every legacy application is attack surface. SMBv1 in 2017 is the canonical example: on countless infected machines the protocol served no purpose whatsoever, it had simply never been switched off. Regularly ask: do we still need this? If the answer is no, switch it off. The cheapest vulnerability to manage is the one in a system you no longer run.

4. Minimize privileges

A vulnerability becomes a catastrophe when the compromised component holds more power than it needs. In the server takeover we analyzed, the vulnerable application ran with full root privileges, so one flaw in one app handed over the entire server. Applications should run with the minimum rights they need, admin accounts should be separate from daily-use accounts, and no credential should open more doors than necessary.

5. Segment your network

Assume that despite everything, one system will eventually be compromised. Network segmentation decides whether that is a contained incident or a company-wide one. If the compromised web server can reach your accounting system, your file shares and your backups, the attacker can too. Separate what does not need to talk to each other.

6. Monitor and prepare backups

Detection matters because the average intrusion is not loud. In the case from our first article, attackers controlled the server for five days and were only discovered by accident. Basic monitoring, unusual load, unknown processes, unexpected outbound traffic, dramatically shortens that window. And backups, offline or otherwise separated, tested by actually restoring them, are the difference between a ransomware incident being an expensive week or an existential threat.

7. Use the free early-warning channels

You do not have to track the vulnerability landscape yourself. In Germany, the BSI (Federal Office for Information Security) publishes security advisories and warnings, operates CERT-Bund as the national response team, and offers the IT-Grundschutz framework as structured, practical guidance, much of it aimed explicitly at smaller organizations. Comparable services exist elsewhere: CISA in the United States (including its Known Exploited Vulnerabilities catalog, a plain list of flaws that are being actively attacked right now), the NCSC in the UK. Subscribing to one of these feeds costs nothing and turns “we did not know” into a phrase you will never have to use.

Where to start when this feels like a lot

If your honest reaction to this list is “we do maybe two of these seven”, you are in the majority of small and medium businesses, and the worst response would be paralysis. Start with visibility: what do we run, is it current, what is reachable from the internet, and what happens if one of those systems falls? That is precisely the set of questions a professional security audit answers, an inventory of your actual exposure with prioritized, concrete steps, instead of a generic product pitch. From there, the seven disciplines above stop being an abstract wish list and become a short, ordered to-do list.

The bottom line

A security vulnerability is not an exotic stroke of fate. It is a normal property of software, with a well-understood lifecycle and, in most cases, a fix that exists long before the damage happens. WannaCry spread through systems whose patch had been sitting available for two months. Log4Shell hurt companies that had no way of seeing into their own software supply chain. MOVEit did not need a flaw in its victims’ code at all.

The pattern behind all three: the gap is rarely knowledge, it is execution. Inventory, patching, minimal privileges, segmentation, monitoring, backups, none of this is spectacular, all of it is achievable at SME scale. The companies that get hit worst are rarely the ones facing the smartest attackers; more often they are simply the ones whose doors have stood open the longest.