There's a mix-up that shows up every time a new CVE drops. Someone on Twitter (or X, whatever it's called these days) says "they found a massive exploit in Log4j" when what actually existed was a vulnerability, and the exploit came later, written by someone else, days after. Sounds like a naming detail, but it isn't. Getting this distinction right changes how you prioritize fixes, how you read a security report, and even how you react when someone sends you that scary link saying "system X is vulnerable." A vulnerability is the flaw itself. A validation that never got written, a data type that wasn't handled properly, a permission setting left too open by mistake. It sits inside the code or the system, quiet, waiting. Sometimes for years. There are CVEs catalogued over a decade ago that never had a publicly known exploit, and that doesn't mean they stopped being real vulnerabilities, it just means nobody, at least not publicly, ever built the tool to abuse them. The exploit is that tool. It's the code, the script, sometimes just a well-crafted sequence of HTTP requests, that takes the crack left by the vulnerability and makes something actually happen. Running a command, leaking memory, escalating a privilege. If the vulnerability is a broken lock, the exploit is the key made to fit it. And this is where a good angle for the article comes in: not every broken lock has an easy key to cut. Some vulnerabilities are theoretically exploitable but require so much engineering, so many conditions lining up just right, that the real-world risk ends up much lower than the CVSS score suggests. That's why exploitability scoring exists separately from severity scoring, and why serious security teams don't patch in the order CVSS dictates, they patch in the order of what has an active exploit circulating. Log4Shell is the example I always reach for when I want to make this concrete. The vulnerability was insecure deserialization of JNDI strings inside Log4j, a behavior that had existed for years without much attention. The exploit was the specific payload, that malicious JNDI lookup people started copying and adapting to different contexts. And then there was a third layer, "weaponization," when that payload became part of automated scanners, botnets, tools any script kiddie could run without understanding a thing about what was happening underneath. Vulnerability, exploit, weapon. Three different stages, each with different implications for whoever's defending the system. One question that always sparks good comments whenever I bring this up in a technical community is whether a PoC counts as an exploit. Proof of concept, that code which only demonstrates the flaw is exploitable, without carrying an actual malicious payload, without doing any real damage beyond proving the point. Some people put it in its own category, some treat it as an incomplete exploit, some think the distinction is irrelevant because in practice any published PoC turns into a working exploit within a day, someone always adapts it. I tend to side with that last group, but I'll admit it's a genuine debate without an obvious answer. Then there's the other angle that always heats up the conversation: disclosure. Publishing vulnerability details, with or without an exploit attached, has been controversial forever. Full disclosure argues that only public pressure forces vendors to fix things fast. Responsible disclosure (or coordinated disclosure, a term that's gained more traction lately) gives the vendor a window to act before anything goes public. And there's a smaller but present camp that believes exploits should never be published, period, because the risk of malicious use outweighs any educational benefit. None of these positions is clearly right, and that's exactly why it drives real discussion in the comments, not something that gets settled with an "it depends" and moves on. On the practical side, for people writing code day to day, here's what it comes down to: the gap between a vulnerability going public and a working exploit showing up in the wild has shrunk quite a bit over the last few years. There have been cases of active exploits circulating in under 24 hours after a CVE dropped. That changes the logic of "I'll fix it whenever." Patching a vulnerability with no known exploit yet is still a priority, because that "yet" has an increasingly short shelf life. There's also a market behind all of this, which I think deserves its own piece somewhere else, but it's worth a mention here: bug bounty programs on one side, paying for responsibly reported vulnerabilities, and on the other a much murkier market paying for working zero-day exploits, sometimes at six-figure sums depending on the target. Both markets exist at the same time, competing for the same raw material, and that alone is enough to spark a real debate about incentives, ethics, and where the money in the security industry actually ends up going. Please consider participating in this post (by voting or commenting), as this really helps us bring you more content like this.