CWE-71 Deprecated: Apple .DS_Store — See CWE-62?

TL;DR: CWE-71 is deprecated — MITRE folded it into CWE-62 (UNIX Hard Link) because the original entry was really just one specific example (involving Apple’s .DS_Store) of that general weakness; if you see CWE-71 referenced anywhere, treat it as CWE-62.

What is CWE-71?

CWE-71 (“DEPRECATED: Apple ‘.DS_Store’”) is a MITRE Common Weakness Enumeration entry that has been officially deprecated. As defined by the MITRE Corporation, this entry existed to describe a specific observed example — involving .DS_Store, the metadata file macOS Finder writes into browsed directories — of a broader weakness type, rather than being its own individual weakness. MITRE’s guidance is explicit: refer to CWE-62 (UNIX Hard Link) instead.

Quick Summary

This page exists so that any tool, scan report, or documentation still citing CWE-71 has somewhere accurate to land — the real, active content lives at CWE-62. The underlying issue in both is the same: an application that opens a file by name without checking whether that name is actually a hard link pointing somewhere outside its intended control sphere can be tricked into operating on a file it never meant to touch.

Jump to: Quick Summary · CWE-71 Overview · How the Underlying Weakness Works · Business Impact of Hard Link Following · Hard Link Following Attack Scenario · How to Detect Hard Link Following · How to Fix Hard Link Following · Framework-Specific Fixes for Hard Link Following · How to Ask AI to Check Your Code for Hard Link Following · Hard Link Following Best Practices Checklist · CWE-71 FAQ · Vulnerabilities Related to CWE-71 · References · Scan Your Own Site

CWE-71 Overview

What: CWE-71 was a specific, now-retired example entry describing a .DS_Store-related hard-link scenario; its content has been consolidated into CWE-62.

Why it matters: Anyone auditing older scan output, documentation, or compliance mappings may still encounter a CWE-71 reference and needs to know it maps to CWE-62 today.

Where it occurs: N/A for CWE-71 itself — see CWE-62 for the active weakness this maps to.

Who is affected: Anyone consuming tooling or reports that haven’t been updated to reflect MITRE’s consolidation of this entry.

Who is NOT affected: Applications that already check file link counts and hard-link targets before operating on files in untrusted directories, per CWE-62’s guidance.

How the Underlying Weakness Works

Root Cause

An application opens a file by name without checking whether that name is a hard link pointing to a target outside its intended control sphere.

Attack Flow

1. The attacker gains write access to a directory the target application processes.
2. The attacker creates a hard link in that directory pointing at a sensitive file outside the intended scope.
3. The application opens the file by name without checking its link count or target.
4. The application’s file operation is silently redirected to the unauthorized target.

Prerequisites to Exploit

• The attacker can create a hard link in a directory the target application processes.
• The application opens files without checking link count or validating the target.
• The hard link’s target is accessible to the process running the application.

Vulnerable Code

FILE *fp = fopen(filename, "r+");
/* read and modify contents, trusting that filename refers to
   the file the application expects, with no link check at all */

fopen() follows the filename directly with no check on whether it’s a hard link to a file outside the intended directory, so an attacker-created hard link silently redirects the operation.

Secure Code

struct stat st;
if (lstat(filename, &st) == 0 && st.st_nlink > 1) {
    /* reject files with more than one hard link in untrusted directories */
    fprintf(stderr, "Refusing to operate on a hard-linked file\n");
    exit(1);
}
FILE *fp = fopen(filename, "r+");

Checking st_nlink before opening the file rejects any file with more than one hard link in an untrusted directory, closing off the redirection path.

Business Impact of Hard Link Following

Confidentiality: Attackers may read the contents of a file outside the application’s intended scope by redirecting a read operation through a hard link.

Integrity: Attackers may cause the application to write to or modify a file they choose, if the operation involves writing through the link.

• Unauthorized access to files the application was never meant to touch
• Difficulty detecting the issue after the fact, since hard links leave no separate “link” object in most file listings

Hard Link Following Attack Scenario

1. An attacker gains write access to a shared, world-writable temp directory a backend service processes.
2. Instead of a normal file, they create a hard link there pointing at a sensitive system file.
3. The service opens the file by name, with no check on its link count, and Unix silently redirects the operation to the sensitive file’s actual data.
4. The service’s read or write operation now affects the sensitive file instead of the expected temp file.

How to Detect Hard Link Following

Manual Testing

• Identify file-processing features that operate on files in shared or attacker-writable directories.
• Create a hard link in that directory pointing at a sensitive file.
• Confirm whether the application follows the link to its target instead of rejecting it.

Automated Scanners (SAST / DAST)

Static analysis can flag file-opening code that doesn’t check link count via stat()/lstat(), while dynamic testing with a crafted hard link confirms whether the live application actually follows it at runtime.

PenScan Detection

PenScan’s scanner engines test file-processing features with crafted hard links to confirm whether targets outside the intended directory are followed.

False Positive Guidance

If the application only processes files in a directory the attacker has no write access to, this weakness is not practically exploitable even without an explicit link-count check — confirm actual directory permissions before treating it as a real finding.

How to Fix Hard Link Following

• Check a file’s link count (st_nlink via stat()/lstat()) before operating on it in an untrusted directory.
• Reject files with more than one hard link where only a single, application-created file is expected.
• Apply least-privilege access so a followed hard link’s target has limited blast radius even if this check is missed.
• Prefer dedicated, application-controlled directories with restrictive permissions over shared, world-writable locations.

Framework-Specific Fixes for Hard Link Following

This weakness is specific to Unix-like filesystems that support hard links; it has no equivalent mechanism on Windows, which uses a different linking model, so no forced-fit example is given for that platform.

• C/C++: check st_nlink via stat()/lstat() before opening a file in an untrusted directory, as shown above.
• Python: use os.stat(path).st_nlink to check the link count before opening a file from a shared directory.
• Java: use Files.readAttributes() to inspect POSIX file attributes, including link count, before processing a file from an untrusted location.

How to Ask AI to Check Your Code for Hard Link Following

Hard Link Following Best Practices Checklist

✅ Check a file’s link count before operating on it in an untrusted directory ✅ Reject files with an unexpected hard-link count ✅ Apply least-privilege access to limit the impact of any followed link ✅ Prefer application-controlled directories over shared, world-writable ones

CWE-71 FAQ

How is CWE-71 different from a normal, active CWE entry?

MITRE deprecated CWE-71 because it turned out to describe one specific observed example — involving Apple’s .DS_Store metadata file — of a broader weakness type, rather than being a distinct weakness in its own right, so it was folded into CWE-62 (UNIX Hard Link).

How should I treat CWE-71 if a scanner or report references it?

Treat any reference to CWE-71 as referring to CWE-62 (UNIX Hard Link) instead, since that is the active entry MITRE consolidated it into.

How does a hard link create a security risk in general?

A hard link makes a filename point to the same underlying file data as another name; if an application opens a file by name without checking whether that name is actually a hard link to something outside its intended scope, it can end up operating on an unauthorized file.

How is a hard link different from a symbolic link for this purpose?

A hard link points directly at the same underlying file data with no separate “link” object visible to most file operations, which can make it harder to detect than a symbolic link, though both fall under the broader Link Following weakness (CWE-59).

How do I detect this kind of weakness in my own application?

Create a hard link from a file the application processes to a sensitive file outside the intended directory, and confirm whether the application follows the link and operates on the unintended target.

How do I fix hard-link-following weaknesses correctly?

Check the file’s link count and inode information before operating on it, reject files with an unexpected link count in untrusted directories, and apply least-privilege access to limit the impact of any followed link.

How can PenScan help find this class of weakness?

PenScan tests file-processing features for unsafe hard-link and symlink resolution to confirm whether attacker-controlled links are followed to unauthorized targets.

Vulnerabilities Related to CWE-71

CWE-71 has no active related-weakness data of its own since it is deprecated; see CWE-62 (UNIX Hard Link) for the current, active entry and its own related weaknesses.

References

• MITRE - CWE-71 (deprecated)
• MITRE - CWE-62 (active entry)
• NVD

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find hard-link and symlink following risks before an attacker does.