Vulnerability Discovery and Analysis
Free CompTIA PenTest+ practice — 6 questions on Vulnerability Discovery and Analysis, with explanations. No sign-up. Full 12-question mixed test →
During an authorized engagement, a vulnerability scanner returns two findings for a client report. Finding A: CVSS base score 9.8 (Critical) for a SQL injection flaw on an internal admin portal reachable only through a VPN requiring MFA, with no known public exploit. Finding B: CVSS base score 6.5 (Medium) for a reflected XSS flaw on the public-facing customer portal, for which the tester manually confirmed a working, publicly available exploit with no compensating controls. Which finding should the tester prioritize as the HIGHER real-world risk in the final report?
CVSS base scores don't account for environmental context or confirmed exploitability. A lower-scored, confirmed-exploitable, internet-facing flaw with no mitigating controls represents higher actual risk than an unconfirmed critical finding behind MFA-protected VPN access. Analysts must apply environmental/temporal context, not just the base score, when prioritizing.
As part of an authorized source code review, a SAST tool flags a 'hardcoded credentials' finding in a configuration file. Manual review of the flagged line shows the value is actually a reference to an environment variable (process.env.API_KEY), not a literal secret. What should the analyst do with this finding?
Manual validation confirmed the flagged string is not an actual secret but a reference to a securely-stored environment variable. The correct analytical step is to document this as a false positive with supporting evidence, which is core to vulnerability analysis and report accuracy.
A software composition analysis (SCA) tool flags a third-party library version as vulnerable to a CVE tied to a specific deserialization method. Manual review of the application's codebase confirms this method is never called or reachable through any code path. What is the MOST defensible action for the tester to take?
Reachability analysis determined the vulnerable function isn't invoked, so current exploitability is low — but the outdated, vulnerable component still exists and should be flagged for patching as a best practice, since future code changes could introduce a call path. This reflects proper risk-based nuance in vulnerability analysis rather than binary true/false-positive labeling.
During dynamic analysis of a compiled binary as part of an authorized engagement, a fuzzer produces a crash. Which action would BEST help the tester determine whether this crash represents an actual exploitable vulnerability rather than a benign fault?
Crash triage with a debugger to check for control over EIP/RIP or other registers is the standard method to determine whether a crash is exploitable (e.g., a buffer overflow overwriting the instruction pointer) versus a harmless application fault.
As part of the physical security testing scope in an authorized engagement, the client wants to know whether their RFID employee badge access system can be cloned by an attacker with brief physical proximity to an employee. Which tool or technique is MOST appropriate for the tester to use to discover this vulnerability?
A Proxmark3 (or similar RFID read/write tool) is the specific device used to test whether an RFID badge's data can be read and cloned at proximity, directly addressing the stated objective of discovering an RFID cloning vulnerability.
An automated vulnerability scan flags a web server as vulnerable to a known CVE based solely on its HTTP response banner reporting 'Apache/2.4.49'. During manual validation, the tester attempts the associated path traversal proof-of-concept exploit and finds it fails; further investigation reveals the vendor backported the security patch into this build without updating the reported version string. How should the tester classify this finding?
Banner grabbing/version detection is a heuristic that can be inaccurate when vendors backport patches without changing version identifiers. Manual exploitation attempts are the correct method to validate exploitability, and the failed PoC combined with confirmation of the backported patch supports classifying this as a false positive.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →