Exploit

An exploit takes a specific condition and drives the target into a state its designers did not intend: control of execution flow, an operation performed as another identity, data returned that should not have been, or a check bypassed. Its reliability depends on the environment, which is why exploitation is a spectrum rather than a yes or no. A single request that works everywhere and a technique that needs a precise memory layout, a specific version and several attempts are both exploits, and only one of them is a commodity risk.

Proof-of-concept code, which demonstrates that the condition can be triggered, is a different artefact from a weaponised exploit that achieves reliable impact on real targets. A great deal of published code is the first kind, which is one reason a public exploit does not automatically mean mass exploitation.

The types most often named describe where it is fired from and what it is fired at. A zero-day exploits a vulnerability for which no security update exists yet, so there is no prepared defence. A remote one arrives over the network; a local one needs prior access to the machine and is usually the step before a privilege escalation. And web application ones, such as SQL injection or cross-site scripting, never touch memory: they abuse the logic of the application itself.

Both directions of the same mistake. Treating a security hole as harmless because no exploit is public ignores that the absence of one is a statement about publication, not about difficulty. Treating every public exploit as an emergency ignores that most of them need conditions your estate does not present.

The way out is measurement rather than opinion. EPSS gives a probability that exploitation will be observed. The KEV catalogue records that it has been. Neither of those is severity, and CVSS alone is not exploitability, which is why a queue sorted on any one of the three is wrong in a different way.

The related error is confining the word to memory corruption. A great deal of what we exploit on engagements involves no code at all: an authorisation check that is absent, a workflow step that can be skipped, a token accepted from the wrong audience. Those are exploits in every sense that matters to the client, and they have no identifier and no patch.

We test exploitation rather than presence, because the difference is what a report is for. Where we run something exploitable in production we agree the boundaries first, prove control with an action that has no side effect, and record precisely what we chose not to do. The finding carries the request, the observed result, the conditions required and the identity obtained, so that a client can distinguish something an opportunist will reach next week from something that needed our specific position in their network. That is the difference between a scanner and a penetration test.