CVE-2017-14849

This vulnerability is about “tricked file paths.” If an attacker can send a special-looking request, your app might be persuaded to open files outside the folder it was supposed to use.
Think of it like a bouncer checking IDs at the door, but a rule change breaks the bouncer’s logic—so someone might slip through with a fake address to the back rooms.

This matters if you run Node.js 8.5.0 and your application (or its libraries) uses community modules that do path validation for user-controlled paths.
The risk is only relevant when an attacker can reach the part of your app that processes request paths for file access, so you mainly need to worry if you expose file-related endpoints over the network.

This is a high-risk file-reading issue, and the fix is straightforward: upgrade Node.js to the fixed version.
Even though this specific issue is not listed in the CISA KEV set and exploitation details aren’t confirmed here, you should treat it as an “amber” priority because it targets remote access to unintended files and the vulnerable version window is well-defined.

1. Confirm exposure (fast):
   • Identify where Node.js runs (web servers, background workers, build/deploy containers).
   • Check the exact Node.js version and whether it is within “Node.js 8.5.0 before 8.6.0.” If you cannot map versions confidently, record node -v outputs per host.
2. Confirm whether your app uses vulnerable patterns:
   • Look for endpoints that let users influence file paths, such as downloads, static file overrides, template-based file reads, or any route that combines user input with filesystem paths.
   • Pay special attention if you use community modules involved in pathname/file handling (the advisory notes the issue can appear when module path validation is incompatible with the Node.js “..” handling behavior).
3. Upgrade remediation (the fix):
   • Upgrade Node.js to 8.6.0 or later.
   • Use the official Node.js guidance linked in the findings (“September 2017: Path validation”).
4. Regression test after upgrade:
   • Re-test the file-related endpoints you identified.
   • Ensure requests that attempt to escape the intended directory return “not found/forbidden” and do not reveal unexpected files.
5. Temporary workaround if upgrading is delayed:
   • Restrict file-serving so that it only uses a fixed, allow-listed directory and a allow-listed set of filenames.
   • Avoid constructing filesystem paths from raw user input; instead, map user inputs to predetermined filenames or IDs and then serve files from the intended directory.
   • Where possible, add strict validation that rejects any path that contains “..” or encoded equivalents, and verify behavior on the specific routes you exposed.
6. What to monitor:
   • After the upgrade, monitor logs for unusual requests to file-serving or download endpoints (requests that contain suspicious path traversal patterns) and confirm they are blocked/denied.

Note on timelines: No CISA KEV due date applies here because this CVE is not listed in CISA KEV in the provided findings.

Severity and type: This is a high-severity (based on the provided CVSS 7.5) path traversal-like issue (CWE-22) that can lead to sensitive information disclosure by allowing unintended file access.
Mechanism: In Node.js 8.5.0 before 8.6.0, a change to handling of “..” path segments can become incompatible with pathname validation performed by some community modules. When that mismatch occurs, crafted requests can bypass intended path checks.
Attack vector: Network-reachable requests that influence paths used for file access.
Exploitation status: Not listed in CISA KEV; no confirmed in-the-wild exploitation claim is included in the provided findings. A predicted exploitation likelihood is provided in the findings, but because KEV/news confirmation is not present here, the public actions should focus on upgrading to the fixed version.
EPSS note: The findings include an EPSS prediction with a downward trend; per instructions, this percentage is not repeated in public owner-facing sections.