The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
View on MITREImproper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
No mitigation information available for this CWE.
No detection method information available for this CWE.
Consider the following source code from a (hypothetical) FTP server:
This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server does not change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.
chroot("/var/ftproot");...fgets(filename, sizeof(filename), network);localfile = fopen(filename, "r");while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {fwrite(buf, 1, sizeof(buf), network);}fclose(localfile);Additional facts reviewed against primary or authoritative security sources.
Documented detection approaches include Automated Static Analysis; recorded impacts include Read Files or Directories; related weaknesses include CWE-573, and CWE-669. Use these source-defined anchors to turn CWE-243 into implementation, review, and verification checks for the affected component.
CWE-243: Creation of chroot Jail Without Changing Working Directory — MITRE CWEUse NIST SSDF practices to make prevention of CWE-243, Creation of chroot Jail Without Changing Working Directory, an explicit development outcome. Translate the CWE definition into security requirements and design constraints, choose safer implementation patterns and toolchain checks, and define acceptance evidence before release. Feed every confirmed occurrence back into the requirements, design review, and coding rules so the same root cause is removed across the product rather than patched in one location.
NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and TechnologyUse CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-243, Creation of chroot Jail Without Changing Working Directory, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.
Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security AgencyApply MITRE's full root-cause mapping guidance when using CWE-243, Creation of chroot Jail Without Changing Working Directory. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.
CVE to CWE Root Cause Mapping Guidance — MITRE CWEApply MITRE's root-cause mapping quick tips to CWE-243, Creation of chroot Jail Without Changing Working Directory. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.
CVE to CWE Root Cause Mapping Quick Tips — MITRE CWECWE-243: Creation of chroot Jail Without Changing Working Directory is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail. Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
If exploited, CWE-243 (Creation of chroot Jail Without Changing Working Directory) it can compromise Confidentiality, leading to outcomes such as Read Files or Directories.
CWE-243 commonly affects C and C++. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
A CWE (Common Weakness Enumeration) like CWE-243 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.