CWE-552: Files or Directories Accessible to External Parties

Extended Description

Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories. In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.

Code Examples & CVEs

Demonstrative Examples

The following Azure command updates the settings for a storage account:

However, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs.

BadShell

az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access true

The following Azure command updates the settings for a storage account:

However, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs.

GoodShell

az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access false

The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':

Suppose the command returns the following result:

BadJSON

{ 		      		       "bindings":[{ 		        			 "members":[ 			  			   "projectEditor: PROJECT-ID", 			   "projectOwner: PROJECT-ID" 			  			 ], 			 "role":"roles/storage.legacyBucketOwner" 		        		       }, 		       { 		        			 "members":[ 			  			   "allUsers", 			   "projectViewer: PROJECT-ID" 			   ], 			   "role":"roles/storage.legacyBucketReader" 			  			 } 		        		       ] 		      		     }

The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':

Suppose the command returns the following result:

GoodShell

gsutil iam ch -d allUsers gs://BUCKET_NAME 			 gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME

Observed CVE Examples (1)

CVE-2005-1835

Data file under web root.

View Details

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-552 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-552, Files or Directories Accessible to External Parties, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Address Files or Directories Accessible to External Parties during Implementation

MITRE associates mitigation with Implementation, System Configuration, and Operation; documented detection approaches include Automated Static Analysis; recorded impacts include Read Files or Directories, and Modify Files or Directories. Use these source-defined anchors to turn CWE-552 into implementation, review, and verification checks for the affected component.

CWE-552: Files or Directories Accessible to External Parties — MITRE CWE

Triage CWE-552 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-552, Files or Directories Accessible to External Parties, 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 Agency

Apply precise root-cause mapping to CWE-552

Apply MITRE's full root-cause mapping guidance when using CWE-552, Files or Directories Accessible to External Parties. 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 CWE

Validate CWE-552 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-552, Files or Directories Accessible to External Parties. 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 CWE

Frequently Asked Questions

What is CWE-552: Files or Directories Accessible to External Parties?+

CWE-552: Files or Directories Accessible to External Parties is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product makes files or directories accessible to unauthorized actors, even though they should not be. Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories. In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.

What are the security consequences of Files or Directories Accessible to External Parties?+

If exploited, CWE-552 (Files or Directories Accessible to External Parties) it can compromise Confidentiality and Integrity, leading to outcomes such as Read Files or Directories and Modify Files or Directories.

How do you prevent or mitigate Files or Directories Accessible to External Parties?+

Recommended mitigations for CWE-552 include: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.

Which programming languages are affected by Files or Directories Accessible to External Parties?+

CWE-552 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Files or Directories Accessible to External Parties?+

MITRE documents real CVEs mapped to CWE-552, including CVE-2005-1835. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-552 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.

CWE-552: Files or Directories Accessible to External Parties

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Phase

Description

Detection Methods