CWE-98 is a weakness where an application lets an attacker influence the filename used by an include or require statement. The program loads a file from user-controlled input instead of a trusted path, which can expose source code, configuration, or executable logic through local file inclusion or related path manipulation.
How CWE-98 works
CWE-98 describes a weakness where application flow lets untrusted input influence an include or require target. That turns a file path decision into code-loading behaviour, which is dangerous because the application may import attacker-chosen local files instead of trusted program logic.
The core problem is not just path handling, it is control over what executable content is loaded. When the filename is derived from user input, the application can cross a trust boundary and expose source code, configuration, template logic, or runtime behaviour that was never meant to be reachable externally.
In practice, this weakness often appears in dynamic page rendering, plugin loading, template selection, or language features that resolve includes at runtime. The security issue is that the loader trusts a filename as though it were an internal reference, even when the value was supplied by a request parameter, header, cookie, or other untrusted source.
Why it is dangerous
Once an attacker can steer an include or require statement, the impact can go well beyond disclosure. Depending on the environment and the file type involved, the application may reveal source code, disclose secrets embedded in configuration, or execute unintended logic that changes application behaviour.
This weakness is closely related to local file inclusion and path manipulation patterns, where file resolution is the attack surface rather than a standalone parser bug. It becomes more severe when the application runs with broad file system access or when sensitive application files are reachable from the web tier.
The exposure is often amplified by weak deployment hygiene. If source trees, build artifacts, debug files, backups, or config directories are left accessible, an include flaw can turn ordinary file access into a much larger confidentiality and integrity problem.
How organisations should assess exposure
The first step is to inventory every include, require, template, and file-loading path, then trace which inputs can influence them. Review source code, framework conventions, and route handlers to identify whether the filename is fixed, derived from a whitelist, or built from request data.
It is also important to test the application as deployed, not only as written. Internet-exposed endpoints, path normalization behaviour, and hosting quirks can change whether a seemingly harmless include becomes exploitable. Security teams should confirm whether sensitive files are reachable through relative paths, traversal sequences, or alternate filename forms.
For higher confidence, compare code review findings with vendor or framework guidance for the exact runtime. Many include-related weaknesses are shaped by platform-specific path resolution rules, so the authoritative advisory for the framework or product is often the best source for exact hardening details.
Remediation and safe design
The safest design is to avoid user-controlled filenames in include or require statements altogether. Where dynamic selection is truly needed, map external input to a fixed set of internal identifiers and resolve only to trusted, predetermined paths.
When a patch or redesign cannot be applied immediately, compensate by reducing reachability and blast radius. Tighten file system permissions, isolate sensitive source and configuration files from web-accessible locations, and remove development artifacts that could aid disclosure if a path is traversed.
Validation should be treated as an allowlist problem, not a sanitization problem. Normalizing a path is not enough if the application still accepts arbitrary filenames; the application must decide which exact targets are permitted and reject everything else.
Detection and post-exploitation review
Monitoring should focus on unusual file access patterns, unexpected include targets, and requests that probe directory structure or alternate encodings. Repeated traversal attempts, odd extension changes, and requests that map to source files are common signs that an attacker is testing the include boundary.
After suspected exploitation, review logs and application traces for evidence that sensitive files were loaded or disclosed. If code execution is possible in the affected path, also examine whether the compromise reached sessions, API keys, database credentials, signing material, or service account secrets that may need rotation.
Because this weakness can expose the application’s own source and configuration, post-incident review should also check for secondary compromise paths. An attacker who learns file layout or secret handling from the code may use that information to pivot into broader environment access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | CWE-98 is a secure coding flaw in runtime file inclusion and trust-boundary handling. |
| V5 — File Handling | The weakness turns file resolution into an attacker-controlled input handling problem. | |
| V16 — Security Logging and Error Handling | Detection depends on logging suspicious file access and include-related failures. | |
| Recommendation — Review file-loading paths under V15 and remove any user-controlled include or require targets. Apply V5 constraints so includes resolve only to vetted, trusted file paths. Log include failures and suspicious path patterns to support detection and review. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The filename source must be validated before it is used in a code-loading operation. |
| AC-6 — Least Privilege | Overbroad file permissions increase the impact when include paths are abused. | |
| Recommendation — Validate and restrict filename input before it reaches any include or require logic. Limit application file access so compromised include paths cannot reach sensitive assets. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This is a software weakness that belongs in secure application design and testing. |
| CIS-6 — Access Control Management | Restricting file and account access limits the damage from arbitrary file inclusion. | |
| Recommendation — Embed secure code review and testing for include and path-handling flaws in CIS-16 work. Restrict application and file system access paths so include abuse cannot expose sensitive content. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misconfigured file exposure and path handling commonly enable file inclusion weaknesses. |
| Recommendation — Harden deployment and path handling so exposed files cannot be reached through include logic. | ||
| MITRE ATT&CK | T1036 — Masquerading | Attackers may use misleading filenames or paths to influence what the application loads. |
| T1006 — Direct Volume Access | The weakness can expose local files and allow direct access to sensitive content on disk. | |
| Recommendation — Hunt for deceptive file names and path manipulation that steer code-loading behavior. Investigate whether local file exposure from the application enabled broader disk-content access. | ||