A business-critical production service looks vulnerable to a memory-corruption exploit that might crash it. What do you do?
Short answer
Rules of engagement usually exclude DoS on production, and an unplanned crash causes real business damage and can void the engagement. Verify scope first; if a destructive proof-of-concept isn't authorized, prove the vulnerability through safer means and clearly document the likely impact. Firing the exploit for a screenshot is reckless. Running it repeatedly for 'reliability metrics' multiplies the outage. Skipping it silently hides a serious, exploitable risk from the client.
Causing an outage on a business-critical system is one of the fastest ways for a pentest to do real harm and lose the client's trust. Memory-corruption exploits are inherently fragile — a near-miss often crashes the service rather than yielding clean control — so they demand extra caution against live production.
Why confirming scope and testing safely is correct
Start with the rules of engagement: many explicitly exclude denial-of-service and destructive testing against production. If crash-prone testing isn't authorized, you do not fire the exploit. Instead, demonstrate the vulnerability through safer signals — version fingerprinting, crash-free triggers, a controlled test against a staging or isolated copy, or evidence that the vulnerable code path is reachable — and document the likely impact and exploitability clearly. If a true proof-of-concept is essential, propose a maintenance window or a non-production replica so the client can consent to the risk.
Why the other options are wrong
- Fire the exploit for a screenshot. A crash is not a clean proof — it is an outage. Causing unplanned downtime on a critical service can trigger financial loss, SLA breaches, and termination of the engagement.
- Run it repeatedly for reliability metrics. This multiplies the damage. Repeated crashes on production turn a single bad decision into sustained disruption — exactly what the client is paying you to avoid.
- Skip it silently. A reachable memory-corruption flaw on a critical service is a high-severity finding. Hiding it because testing it is risky leaves the client blind to a serious threat. The professional path is to report it with appropriate caveats.
What an interviewer is probing
They want judgment under the tension between thoroughness and safety. The strong answer neither recklessly crashes production nor cowardly omits the issue — it scopes, tests safely, proposes a controlled way to confirm, and documents honestly.
Likely follow-ups
- How can you evidence a memory-corruption bug without triggering a crash?
- What would you propose to safely confirm exploitability — e.g., a maintenance window or staging?
- How do you communicate residual uncertainty when you can't fully prove exploitation?