Vulnerability and exploitation interview questions

Questions and answers

5 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   What is the difference between a vulnerability, an exploit, and a payload?

   A vulnerability is a flaw — a missing bounds check, an authorization gap, an unsafe deserialization path. An exploit is the technique or code that reliably turns that flaw into unintended behavior, such as control of execution or of a privileged operation. The payload is what runs once the exploit succeeds: a reverse shell, a loader, a credential dump. The distinction matters when prioritizing, because a vulnerability with no known reliable exploit against your configuration is a different risk from one with a weaponized exploit in commodity toolkits — that gap is exactly what KEV listings and EPSS scores try to express.

2. Question 2

   How does a stack buffer overflow work, and what stops it on a modern system?

   A stack overflow happens when a program writes past the bounds of a stack buffer and overwrites adjacent memory such as saved registers or a return address, letting an attacker redirect execution. Modern platforms layer mitigations against exactly that: stack canaries detect the overwrite before a function returns, DEP/NX makes injected data non-executable, ASLR randomizes where code and stack live so hardcoded addresses fail, and control-flow integrity constrains indirect branches. Attackers respond with return-oriented programming and information leaks that defeat randomization, which is why mitigations are layered rather than singular. The strategic answer is that memory-safe languages remove the bug class entirely, and that is why large vendors are migrating parsers and network-facing components first.

3. Question 3

   A critical CVE just dropped. How do you decide whether to panic?

   First I establish whether we are actually affected: which versions and configurations are vulnerable, and does the vulnerable feature exist and get reached in our deployment — plenty of critical CVEs need a non-default option enabled. Then exposure: is the asset internet-facing, authenticated, or reachable only from an internal segment, and what does compromise of it reach. Then exploitability signal: whether it is in CISA's Known Exploited Vulnerabilities catalog, whether public proof-of-concept code exists, and what EPSS says about likelihood of exploitation. That produces a decision — emergency patch, scheduled patch, or compensating control such as a WAF rule, feature disable, or network restriction — and in every case I add detection for exploitation attempts, because patching all of a large estate is never instant.

4. Question 4

   Why do defenders think in attack chains rather than single vulnerabilities?

   Real intrusions are sequences: initial access, execution, persistence, privilege escalation, credential access, lateral movement, and finally impact or exfiltration. Each link is an opportunity — breaking any one of them stops the objective, so a mitigation that is cheap and reliable at the credential-access stage can be worth more than an expensive fix at initial access. This framing also shapes detection, because behavior late in the chain is often noisier and higher-confidence than the initial delivery, which may be a perfectly ordinary-looking email. In an interview it is worth naming ATT&CK as the shared vocabulary for this and giving one concrete example of a control that breaks a specific link.

5. Question 5

   You find an unreported vulnerability in a third-party product. What do you do?

   I stop at proof of existence — enough evidence to demonstrate the flaw, without pivoting further, touching other tenants' data, or testing anything outside the authorization I have. I document the finding precisely: affected version, reproduction steps, impact, and the environment it was observed in. Then I report through the vendor's coordinated disclosure or bug bounty channel, or through a national CERT if none exists, and agree a disclosure timeline rather than publishing immediately. Internally I raise the risk to our own owners so compensating controls go in while the vendor fixes it. Interviewers ask this to check restraint and legal awareness as much as technical skill, so saying the boundary out loud matters.