What is an exploit?

An exploit is neutral in itself. Security teams write and run exploits to prove a weakness is real; attackers run them to break in.

• Vulnerability. The weakness: a missing check, a parsing bug, an unsafe default. It can exist for years without harming anyone.
• Exploit. The means of using it: a request with a crafted parameter, a malformed file, a script that runs the steps.
• Attack. An exploit used against a real target, with a real effect.

When no fix exists yet, all three get the prefix zero-day; zero-day explains why that word describes the fix rather than the attack.

• Remote and local. A remote exploit works over the network with no prior access; a local one needs the attacker to already run something on the machine, often to gain more privileges.
• Known and zero-day. A known exploit targets a published vulnerability that has a fix, which many systems still lack; a zero-day exploit targets one with no fix yet.
• Web application exploits. Requests that abuse how an application handles input, such as SQL injection or command injection.
• Client-side exploits. Malicious pages or files that use a flaw in a browser, document reader or plugin when a user opens them.
• Exploit kits. Packaged toolsets that probe a visitor's software and deliver a matching exploit automatically, sold or rented to people who could not write the exploits themselves.

Most real attacks use known exploits, not zero-days. Scanning the internet for systems that still lack a months-old fix is cheaper than finding a new flaw.

Vulnerabilities get CVE identifiers, and the NVD adds severity scores and affected versions. Severity says how bad a flaw would be if used, not whether anyone uses it, so two other sources matter for priorities.

The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild. The Exploit Prediction Scoring System from FIRST estimates the probability that a vulnerability will be exploited in the coming days. Public exploit databases collect proof-of-concept code, which helps defenders test and also lowers the effort for attackers.

Against a website, an exploit usually arrives as an HTTP request: a parameter carrying database syntax, a path climbing out of its folder, a header with a payload a vulnerable component will parse. Many follow published examples closely, because attackers copy them, and that is what makes them recognisable.

Refusing requests with a known exploit shape while the vulnerable code waits for its fix is virtual patching. It covers the variants someone anticipated, not every variant, so it buys time rather than replacing the fix.

1. Know what you run. An inventory of software and versions is the only way to know which new vulnerabilities apply to you.
2. Patch by exploitation, not only by score. Anything in the KEV catalog or with a high EPSS probability goes first.
3. Reduce what is reachable. Services, admin panels and old endpoints that are not exposed cannot be exploited from outside.
4. Filter in front of applications. Requests matching known exploit patterns can be refused while fixes are applied.
5. Watch for the effect. New processes, unexpected outbound connections and sudden data volumes show an exploit that got through.