Network Security Vulnerabilities: What Actually Gets Exploited

Quick answer: most network security incidents don't come from a novel attack technique. They come from a small, repeating list: software nobody patched, a password that was never rotated off its default, a port left open to the internet that never needed to be, a firewall rule too broad to notice, and a protocol like Telnet or plain HTTP still moving data in the clear. None of these require a sophisticated attacker to find. They're the network's equivalent of an unlocked door, boring, well understood, and still the way most people actually get in.

This isn't a list to memorize. It's a list to check against your own network, because the fix for almost every item on it is configuration, not a rewrite.

The vulnerabilities that actually get exploited

Unpatched software. Vendors ship patches because a specific, known flaw has been found and fixed, publicly, which means an unpatched system isn't hiding from an unknown threat, it's sitting exposed to a documented one. The 2017 Equifax breach, which exposed the personal data of roughly 147 million people, traced back to a known Apache Struts vulnerability that had a patch available for months before the breach happened. The vulnerability wasn't the hard part. Not applying the patch was.

Default or weak credentials. A password that shipped with the device and was never changed isn't really a password, it's public information. The Mirai botnet, which knocked major sites offline in 2016, spread almost entirely by scanning the internet for IoT devices still running factory-default admin credentials. Nothing about that attack was sophisticated. It just worked, repeatedly, because the default credential was never rotated.

Open ports with no reason to be open. Every open port is a door someone can knock on. Telnet (23), unencrypted FTP (21), and exposed database ports like MySQL's 3306 or RDP's 3389 are the ones that show up most often reachable from the public internet with no business reason to be. If a service doesn't need to be internet-facing, it shouldn't be, full stop, put it behind a VPN or a firewall rule scoped to known IPs instead.

Firewall rules broader than the traffic that needs them. A firewall configured to "allow most things, deny a few" inverts the actual security model. The safer default is deny-by-default: block everything, then open only the specific ports and sources a service actually requires. Misconfigured rules are also one of the most common causes of publicly exposed cloud storage, a bucket or database left reachable because a permission was set to "anyone" during testing and never locked back down.

Insecure protocols moving data in the clear. Telnet and plain HTTP send everything, including credentials, as plain text on the wire. Anyone positioned to intercept that traffic, a compromised router, a hostile network, a man-in-the-middle position, reads it without needing to break any encryption, because there isn't any. SSH and HTTPS exist specifically to close this gap, and an HTTPS site still needs a Strict-Transport-Security header to stop a visitor's very first request from being silently downgraded to plain HTTP before the redirect kicks in, a specific header gap covered in more detail here.

What it actually costs when one of these gets used

None of the five above cause damage by existing. They cause damage when someone finds them, and the cost shows up in a few predictable places:

• Data exposure. Once access is gained, whatever the compromised system can reach is exposed too, customer records, credentials, internal documents.
• Downtime. A compromised system taken over for a botnet, or a network deliberately disrupted, stops doing its job, and everything depending on it stops with it.
• Direct financial cost. Incident response, legal fees, and the security work that should have happened before the breach, now happening after, all cost more reactively than they would have proactively.
• Regulatory exposure. In regulated industries, a breach involving personal data isn't just a technical incident, it's a reporting obligation, and sometimes a penalty.

Closing the gaps

Patch on a schedule, not on memory. Automated update systems exist specifically so patching doesn't depend on someone remembering. Where automatic updates aren't safe for a given system, a fixed patch-review cadence is the minimum viable substitute.

Replace default credentials before anything else goes live. This is the single fastest fix on this entire list, changing a default password takes minutes, and multi-factor authentication closes most of what's left even if a password does eventually leak.

Audit what's actually reachable from the outside. A network audit isn't just an internal review of configuration, it should include checking what a stranger on the internet can actually see and reach: which ports respond, which services are exposed, which credentials or headers are missing. That's an external, not just internal, question.

Train people on the threats that actually target them. Phishing and social engineering don't exploit a misconfigured server, they exploit a person clicking something they shouldn't. Technical controls don't cover that gap; awareness does.

Segment the network so one compromise doesn't become every compromise. A flat network means anything an attacker reaches, they can move laterally from. Segmentation turns "we got in" into "we got into one small piece," which is a very different incident.

Why this list doesn't really change

New attack techniques get headlines. The five vulnerabilities above don't, because they're old, well documented, and still work, which is a more useful signal than it sounds like: attackers use what's reliable, not what's novel. AI is increasingly showing up on both sides of this, used to find these same gaps faster and used to defend against them faster, but it hasn't replaced the underlying list. The fundamentals haven't moved. What's changed is how quickly both sides can act on them.

Final Thoughts

Every item on this list is checkable in an afternoon, and every item stays unchecked for the same reason: nothing about "it works" reveals that any of them are missing. A network with an open Telnet port and a network with none look identical from the inside, right up until someone outside the team goes looking.

That's the actual argument for checking rather than assuming. Not that these vulnerabilities are exotic, they're the opposite, but that ordinary, unglamorous gaps are exactly the ones nobody schedules time to look for.