Vulnerability Management practice questions

Session hijacking via cross-site scripting (XSS)

Why it fails: Session hijacking via XSS would require the attacker to successfully inject and execute malicious JavaScript in the victim's browser, typically using document.cookie to exfiltrate the session token. This scenario describes no injection vector or client-side script execution; instead, the weakness lies entirely in the server-side token generation algorithm (username plus low-granularity timestamp). Because the attacker can compute valid tokens offline without any interaction with the victim, the flaw is predictable token generation, not script-based theft.

Session replay attack

Why it fails: A session replay attack involves capturing a valid token and reusing it later to impersonate the same user. The vulnerability described allows the attacker to create a token for a different user, not replay a captured one.

Session fixation

Why it fails: Session fixation occurs when an attacker forces a victim to use a session token that the attacker knows. Here, the attacker is able to compute a token for the victim without any interaction, so it is prediction, not fixation.

The low-severity issue on the offline lab VM.

Why it fails: An offline lab VM presents no reachable attack surface, so its low-severity finding cannot be exploited until the host is powered on and networked. Severity scoring tempts prioritisation here, but remediation order should follow exposure and exploitability; the internet-facing server with an available exploit is the urgent case.

The medium-severity issue on the payroll server with no known exploit.

Why it fails: The payroll server carries no known exploit, so the medium finding lacks an active exploitation path despite touching sensitive data. Asset value alone tempts escalation, yet a critical flaw on an internet-facing host with a published exploit is already weaponisable; exposure plus exploit availability outranks internal data sensitivity.

The high-severity issue on the test workstation that is not domain joined.

Why it fails: The internet-facing web server with a critical, exploitable vulnerability carries the highest realistic risk; the test workstation is isolated and not domain joined. It is tempting because severity labels look comparable, and it would be correct if the workstation were reachable and held sensitive data.

Close the finding as fixed because the reverse proxy reduces the risk

Why it fails: Marking the finding as fixed is incorrect because the scanner is reporting a real TLS configuration weakness in the origin server itself, not in the reverse proxy. A compensating control that terminates TLS at the proxy does not remediate the vulnerable component; the backend may still be directly accessible or misconfigured for internal communications. Closing the finding as fixed without documenting the proxy as an exception removes visibility and accountability, and any future change to the proxy could instantly expose the underlying issue.

Mark the finding as a false positive and remove it from future scans

Why it fails: Marking this as a false positive is wrong because the scanner is accurately detecting a real TLS misconfiguration on the host, even though a reverse proxy mitigates exposure to external clients. A false positive means the reported issue does not exist, but here the issue is present and only compensated for at another layer. Removing the finding from future scans could hide the risk entirely, and if the compensating control changes or is misconfigured, the organization would have no automated alert or documented record to prompt corrective action.

Ignore the finding until the vendor releases a new version

Why it fails: Ignoring the finding while waiting for a vendor patch is not acceptable because it fails to document a named risk owner, a mitigation strategy, or a follow-up timeline. In many cases a patch may never be released, or the vulnerability could be mitigated sooner through configuration changes or virtual patching, but ignoring the report precludes those options. A formal exception with a review date is the appropriate way to defer remediation, as it maintains accountability and ensures the risk is monitored until a permanent fix is available.

Avoid the risk by shutting down the finance application immediately.

Why it fails: Avoidance would eliminate the vulnerability's exposure by taking the application offline, but that action would also halt a critical business service that the organization has determined must remain available for the next six months. In this scenario, the availability impact of a shutdown exceeds the security impact of the known vulnerability. Compensating controls are preferable because they preserve the service while actively reducing the likelihood or blast radius of an exploit.

Transfer the risk by asking the vendor to guarantee that no incident will occur.

Why it fails: Risk transfer does not mean obtaining a promise of perfect security; it typically shifts the financial impact of a loss to an insurer or a vendor through a contract, yet the actual technical vulnerability remains exploitable. A vendor guarantee cannot prevent an attack or protect the finance application's data, and no vendor will accept unlimited liability. Furthermore, the organization retains responsibility for safeguarding its own assets, so this proposed 'transfer' is neither practical nor effective as a risk treatment.

Accept the risk because any delay in patching is automatically low priority.

Why it fails: Risk acceptance is a formal decision made only after a thorough assessment shows that the residual risk is within the organization's risk appetite, and it must be documented and approved by management. A known vulnerability in a finance application directly affects confidentiality and integrity, so classifying it as automatically low priority just because the patch is delayed is unsound. Without compensating controls or a risk-based justification, unwarranted acceptance leaves the organization exposed to potential financial fraud or data loss, violating security governance principles.

Default credentials

Why it fails: Default credentials are a distinct authentication flaw (e.g., unchanged vendor accounts like admin:admin). This scan result only indicates that the administrative SSH service is reachable on all interfaces; it provides no evidence about the passwords or usernames configured. Exposed management service would remain a risk even with strong credentials, because the attack surface is the network reachability itself.

Outdated component

Why it fails: An outdated component finding requires version or patch-level information, typically from banner grabbing or CVE correlation. The scan clue here is the service's network exposure (listening on all interfaces) rather than an end-of-life or unpatched software version. Overstating the issue as outdated would misattribute the root cause, which is improper network segmentation of the management service.

Weak permissions

Why it fails: Weak permissions usually concern file, folder, or object access controls, such as world-writable SSH private keys or lax configuration file modes. The vulnerability scan's finding about an exposed administrative SSH service points to a network boundary issue, not a filesystem permission problem. The correct remediation is restricting the service to a management VLAN or jump host, not modifying ACLs on files.

Ignore the finding because the scanner is clearly wrong

Why it fails: Ignoring the scanner's finding outright is risky because false positives still require formal validation and documentation before they can be dismissed. The reported vulnerability may represent a genuine exposure on the Linux server, and without verifying the package version, patch status, and exploitability, the organization could remain blind to a critical threat. All findings should be triaged through the vulnerability management process, not dismissed based on assumption.

Reinstall the disabled plugin so the scanner output matches the running configuration

Why it fails: Reinstalling a disabled plugin to align the scanner's output with the running configuration is a form of security by obscurity that only increases the attack surface. The vulnerable package remains present, and re-enabling it could make the flaw actively exploitable instead of dormant. The goal of vulnerability management is to eliminate or mitigate the underlying issue, not to make the scan report look clean.

Expose the server to the internet for faster monitoring and patch testing

Why it fails: Exposing an internal server to the internet would exponentially increase its risk profile by making it discoverable and reachable by any external actor, thereby inviting attacks from the broader threat landscape. Faster monitoring and patch testing do not require public exposure; they can be accomplished using internal jump boxes, patch management servers, or isolated test networks. This action directly contradicts the security objective and is never an appropriate remediation step.

Increase the password length policy and leave the console publicly reachable.

Why it fails: Lengthening passwords only affects future password choices; it does nothing to reduce the current exposure of the management console to the internet. The console remains reachable by anyone, allowing brute-force attempts, credential-stuffing, or exploitation of any vulnerability in the web interface itself. Even with a strong password, the device's administrative functions are still publicly accessible, which is an unnecessary and direct attack surface. Access control (e.g., IP whitelisting) is a more immediate and effective mitigation than a policy change.

Disable the management interface entirely and replace the device immediately.

Why it fails: Immediately disabling the management interface and replacing the device is a heavy-handed, costly response that ignores the actual scope of the finding. The management interface is often required for routine administration, monitoring, and configuration changes; removing it entirely could cripple operations even if a less disruptive control would suffice. Replacement also introduces deployment time and procurement cost, and the same vulnerability could remain if the replacement is not properly configured. The scan indicates a misconfiguration (public exposure with default credentials), not necessarily a hardware defect that mandates replacement.

Apply a patch after the next quarterly maintenance window and keep the current exposure unchanged.

Why it fails: Delaying remediation until the next quarterly maintenance window leaves the print server exposed to the internet with both a public management interface and known default credentials. A patch, if one exists, may address a specific software vulnerability but does not fix the configuration issue of open administration access or change the vendor-supplied credentials. During the waiting period, the device is a high-priority target because the default credentials are publicly documented, making unauthorized access trivial. Immediate actions—such as restricting network access and rotating credentials—are safer than waiting for a scheduled patch cycle.

Install the patch on all servers immediately without testing

Why it fails: Installing a critical patch fleet-wide without any pre-deployment validation bypasses the change management controls that exist precisely to catch conflicts with existing software, driver, or configuration states. Production environments often host interdependent applications, and an untested patch can introduce service interruptions, data corruption, or security regressions (e.g., breaking authentication modules). The 'speed' of immediate deployment is illusory if it forces an emergency rollback under duress, and it violates the fundamental patch management principle of test before deploy.

Wait until the next quarterly maintenance window to avoid any risk

Why it fails: Delaying a known critical patch until the next quarterly maintenance window leaves the fleet exposed to active exploitation for weeks or months, which is an unacceptable risk posture for a vulnerability with a known exploit. Many real-world breaches occur within days or even hours of a public vulnerability disclosure, and threat actors actively scan for unpatched systems. While change windows help manage routine maintenance, critical security patches require an expedited process; the quarterly window is a schedule convenience, not a security control. Waiting also allows the vulnerability to propagate laterally across the network if one host is compromised before patching occurs.

Patch only one production server and assume the rest will be fine

Why it fails: Patching only one production server is ineffective because it leaves the overall environment with inconsistent security postures, and attackers will simply target the remaining vulnerable hosts. This approach also creates a false sense of security, as the 'patched' server may still be reachable from compromised unpatched peers, allowing lateral movement. Furthermore, a single test in production is not a substitute for controlled testing in a staging environment—it validates nothing about scalability, dependencies, or fleet-wide behavior. Proper remediation requires comprehensive coverage; partial patching is a common cause of residual risk and audit findings.