Components with Known Vulnerabilities

What Is Components with Known Vulnerabilities?

Components with known vulnerabilities is the most asymmetric class of bug on the OWASP top ten. The defender's information is the same as the attacker's, both read the CVE feed, but the attacker only needs the flaw open in one place for one hour after publication; the defender has to find the matching version in their dependency tree, schedule the fix, test it, and deploy. Manual processes lose this race; automated ones (a dependency scanner in CI, a feed subscription that fires on lockfile hits) collapse the response window from days to hours. This exercise puts you on both sides. As Bob, you probe Verric's dashboard-import feature, learn from its own response that it rebuilds uploads with statepack@2.4.1 , look up the freshly published CVE-2025-31782 against it, and send a crafted file whose proof-of-concept payload the library reconstructs into a running process, dumping the server's secrets into a crash log. As Alice, on the receiving end of a data-loss alert, you open the import handler, confirm the vulnerability is the pinned version and not your code, bump to the patched 2.4.6 , switch to a data-only rebuild so a future flaw cannot reintroduce it, and re-run the exact attack to prove it is inert. The exercise closes with quiz questions on why the post-publication window is so dangerous, what automated scanning actually buys, and which defense-in-depth layer survives even when a component has an undiscovered bug.

What You'll Learn in Components with Known Vulnerabilities

• Recognize known-vulnerability exposure as the gap between CVE publication and deployment of the patched dependency, and automated scanning as the control that shrinks it
• Read a CVE advisory and map its affected versions against a project's pinned dependency
• Apply the dependency bump as the immediate fix and the OSV, Snyk, Dependabot, or npm-audit CI integration as the systemic fix
• Understand that a vulnerable component can execute attacker-supplied input even when the surrounding application code is written correctly
• Add defense in depth for deserialization: rebuild untrusted input as plain data, never as rich typed objects, and run the service under least privilege

Components with Known Vulnerabilities — Training Steps

1. The import feature

   Verric lets a customer export a saved dashboard as a small file and import it into another workspace. The import is not done in the browser: Verric's own servers read the uploaded file and rebuild the dashboard from it. Bob opens the feature to see how it works before he touches it.

2. Where the file is rebuilt

   One line on that page is the whole reason Bob is interested.

3. Import a normal file

   First, watch the feature behave normally. Bob attaches an ordinary exported dashboard and imports it. The browser's Network panel records the request and the server's reply, exactly what a developer sees in DevTools.

4. What rebuilt the file

   The dashboard imported cleanly. One field in the response is more useful to Bob than the import itself.

5. Look up the library

   Bob opens a public package registry to see what has been reported against that library. He types the registry address into the browser himself, then searches for it.

6. Check the pinned version

   The latest release, 2.4.6, is clean. Bob needs the version Verric actually runs, 2.4.1, the one the import response named. He selects it from the version list to see its security status.

7. Start from a normal file

   Bob opens an ordinary exported dashboard in his editor. Right now it is exactly what it looks like: a title and a chart.

8. Weaponize the file

   Bob edits one field. He swaps the chart widget for a process-spawning type carrying a shell command, straight from the advisory's proof of concept. The file still parses as a dashboard.

9. The gadget

   Two lines are all it took.

10. Upload the crafted file

    Bob imports his crafted file through the same feature. To the browser it is just another upload.