Skip to content
Insights · weakness

CWE-22: Improper Limitation of a Pathname to a Restricted Directory

Sources read 2026-10-29. MITRE's own page · All weakness notes · Added to CISA's list in the last seven days

What it is

From MITRE's CWE catalogue

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

MITRE classes it as a base-level weakness and rates the likelihood of exploit as high.

What it lets an attacker do

From MITRE's CWE catalogue

  • Execute Unauthorized Code or Commands (affects: integrity, confidentiality, availability)
  • Modify Files or Directories (affects: integrity)
  • Read Files or Directories (affects: confidentiality)
  • DoS: Crash, Exit, or Restart (affects: availability)

On CISA's exploited list

From CISA's exploited list

6 of the 108 entries CISA added from 2026-08-02 to 2026-10-30 name CWE-22, against 3 of 69 in the 90 days before. Over the whole catalogue 82 entries name it. The counts are small, so read them as a rough order, not a rate.

CISA's list is not every flaw that is exploited: it holds the ones CISA has evidence of, listed on the day it added them.

  • CVE-2025-61624, Fortinet Multiple Products, added 2026-10-16
  • CVE-2021-3199, ONLYOFFICE Docs, added 2026-10-08
  • CVE-2026-104286, Fortinet FortiMail, added 2026-10-01
  • CVE-2026-93616, Check Point Multiple Products, added 2026-09-22
  • CVE-2026-66384, JFrog Artifactory, added 2026-08-27

How MITRE says to find it

From MITRE's CWE catalogue

  • Automated Static Analysis
  • Manual Static Analysis
  • Automated Static Analysis - Binary or Bytecode
  • Manual Static Analysis - Binary or Bytecode
  • Dynamic Analysis with Automated Results Interpretation

What MITRE suggests

From MITRE's CWE catalogue

These are MITRE's suggestions, quoted as it gives them. They are not a complete fix and not a substitute for reading the vendor's advisory for the product you run.

  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174).
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].

Attack patterns MITRE links to it

From MITRE's CWE catalogue

Start with one piece of work.

Give us one piece of work and read access to one system. We map it and come back with what we found, what we would build and what it would take — before any commitment. You decide using our output, not our pitch.

Talk to us