CISA KEVC :: 2026-10-05
Report Window: 2026-10-05 to 2026-9-28
| Scoring Source | CRITICAL | HIGH | MEDIUM | LOW | ||||
|---|---|---|---|---|---|---|---|---|
| Today | L7D | Today | L7D | Today | L7D | Today | L7D | |
| EPSS | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 4 |
| CVSS v4.0 | 0 | 2 | 0 | 1 | 0 | 0 | 0 | 0 |
| CVSS v3.1 | 0 | 4 | 0 | 1 | 0 | 0 | 0 | 0 |
| CVSS v3.0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| CVSS v2.0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Today / Last 7 Days count, by severity and scoring source.
CVEs (Today)
0
CVEs (L7D)
6
CWEs (Today)
0
CWEs (L7D)
7
CISA Catalog of Known Exploited Vulnerabilities
Individual vulnerabilities confirmed as actively exploited, with EPSS and CVSS scoring by source.
CVE-2026-102489
Zammad GmbH Zammad Session Fixation Vulnerability
EPSS
LOW
0.01
CVSS v4.0
CRITICAL
9.40
CVSS v3.1
CRITICAL
9.80
Date Added: 2026-10-02
Description
Zammad GmbH Zammad contains a session fixation vulnerability that can lead to remote code execution as the zammad user. This vulnerability can be chained with CVE-2026-102490.
Required Action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
CVSS v3.1
| Source | nvd@nist.gov | Type | Primary |
|---|---|---|---|
| Base Score | 9.8 | Base Severity | CRITICAL |
| Attack Vector | NETWORK | Attack Complexity | LOW |
| Privileges Req. | NONE | User Interaction | NONE |
| Scope | UNCHANGED | Confidentiality | HIGH |
| Integrity | HIGH | Availability | HIGH |
| Exploitability | 3.9 | Impact Score | 5.9 |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | ||
Status:
Analyzed
| Vendor: |
| Zammad GmbH |
| Product: |
| Zammad |
| EPSS: |
| 0.005820000 |
| Percentile: |
| 0.458350000 |
| Related CWEs: |
| CWE-384 |
CVE-2026-102490
Zammad GmbH Zammad Improper Privilege Management Vulnerability
EPSS
LOW
0.00
CVSS v4.0
CRITICAL
9.40
CVSS v3.1
CRITICAL
9.80
Date Added: 2026-10-02
Description
Zammad GmbH Zammad contains an improper privilege management vulnerability that can allow the local zammad user to escalate privileges to root. This vulnerability can be chained with CVE-2026-102489.
Required Action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
CVSS v3.1
| Source | nvd@nist.gov | Type | Primary |
|---|---|---|---|
| Base Score | 9.8 | Base Severity | CRITICAL |
| Attack Vector | NETWORK | Attack Complexity | LOW |
| Privileges Req. | NONE | User Interaction | NONE |
| Scope | UNCHANGED | Confidentiality | HIGH |
| Integrity | HIGH | Availability | HIGH |
| Exploitability | 3.9 | Impact Score | 5.9 |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | ||
Status:
Analyzed
| Vendor: |
| Zammad GmbH |
| Product: |
| Zammad |
| EPSS: |
| 0.002620000 |
| Percentile: |
| 0.163360000 |
| Related CWEs: |
| CWE-269 |
CVE-2026-104286
Fortinet FortiMail Path Traversal Vulnerability
CVSS v3.1
CRITICAL
9.80
Date Added: 2026-10-01
Description
Fortinet FortiMail contains a path traversal and an improper neutralization of NULL byte or NULL character vulnerability that may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests.
Required Action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
CVSS v3.1
| Source | psirt@fortinet.com | Type | Secondary |
|---|---|---|---|
| Base Score | 9.8 | Base Severity | CRITICAL |
| Attack Vector | NETWORK | Attack Complexity | LOW |
| Privileges Req. | NONE | User Interaction | NONE |
| Scope | UNCHANGED | Confidentiality | HIGH |
| Integrity | HIGH | Availability | HIGH |
| Exploitability | 3.9 | Impact Score | 5.9 |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | ||
CVE-2026-76504
Cisco Catalyst SD-WAN Manager Hex Encoding Vulnerability
CVSS v3.1
CRITICAL
9.80
Date Added: 2026-09-30
Description
Cisco Catalyst SD-WAN Manager contains a hex encoding vulnerability that could allow an unauthenticated, remote attacker to access an affected system with privileges of the admin user due to improper handling of URI encoding in an HTTP request.
Required Action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
CVSS v3.1
| Source | psirt@cisco.com | Type | Secondary |
|---|---|---|---|
| Base Score | 9.8 | Base Severity | CRITICAL |
| Attack Vector | NETWORK | Attack Complexity | LOW |
| Privileges Req. | NONE | User Interaction | NONE |
| Scope | UNCHANGED | Confidentiality | HIGH |
| Integrity | HIGH | Availability | HIGH |
| Exploitability | 3.9 | Impact Score | 5.9 |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | ||
Status:
Analyzed
| Vendor: |
| Cisco |
| Product: |
| Catalyst SD-WAN Manager |
| EPSS: |
| Percentile: |
| Related CWEs: |
| CWE-177 |
CVE-2026-86950
Apple Multiple Products Out-of-Bounds Write Vulnerability
EPSS
LOW
0.01
CVSS v3.1
HIGH
8.80
Date Added: 2026-09-29
Description
Apple iOS, macOS, and iPadOS contain an out-of-bounds write vulnerability in CoreGraphics that may lead to arbitrary code execution.
Required Action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
CVSS v3.1
| Source | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | Type | Secondary |
|---|---|---|---|
| Base Score | 8.8 | Base Severity | HIGH |
| Attack Vector | NETWORK | Attack Complexity | LOW |
| Privileges Req. | NONE | User Interaction | REQUIRED |
| Scope | UNCHANGED | Confidentiality | HIGH |
| Integrity | HIGH | Availability | HIGH |
| Exploitability | 2.8 | Impact Score | 5.9 |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H | ||
Status:
Analyzed
| Vendor: |
| Apple |
| Product: |
| Multiple Products |
| EPSS: |
| 0.008120000 |
| Percentile: |
| 0.552950000 |
| Related CWEs: |
| CWE-787 |
CVE-2026-88779
Citrix NetScaler Improper Restriction of Operations within the Bounds of a Memory Buffer Vulnerability
EPSS
LOW
0.00
CVSS v4.0
HIGH
8.70
Date Added: 2026-10-04
Description
Citrix NetScaler ADC (formerly Citrix ADC) and Citrix NetScaler Gateway (formerly Citrix Gateway) contain an improper restriction of operations within the bounds of a memory buffer vulnerability that could allow for a denial of service.
Required Action
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
CVSS v4.0
| Source | 50a63c94-1ea7-4568-8c11-eb79e7c5a2b5 | Type | Secondary |
|---|---|---|---|
| Base Score | 8.7 | Base Severity | HIGH |
| Attack Vector | NETWORK | Attack Complexity | LOW |
| Privileges Req. | NONE | User Interaction | NONE |
| Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X | ||
Status:
Received
| Vendor: |
| Citrix |
| Product: |
| NetScaler |
| EPSS: |
| 0.002760000 |
| Percentile: |
| 0.182030000 |
| Related CWEs: |
| CWE-119 |
Common Weakness Enumeration
The underlying weakness patterns behind the vulnerabilities above — root-cause categories, not individual exploits.
CWE-119
Improper Restriction of Operations within the Bounds of a Memory Buffer
Status: Stable
Description
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Diagram
Alternate Terms
| Term | Description |
|---|---|
| Buffer Overflow | This term has many different meanings to different audiences. From a CWE mapping perspective, this term should be avoided where possible. Some researchers, developers, and tools intend for it to mean "write past the end of a buffer," whereas others use the same term to mean "any read or write outside the boundaries of a buffer, whether before the beginning of the buffer or after the end of the buffer." Others could mean "any action after the end of a buffer, whether it is a read or write." Since the term is commonly used for exploitation and for vulnerabilities, it further confuses things. |
| buffer overrun | Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow." See the alternate term for "buffer overflow" for context. |
| memory safety | Generally used for techniques that avoid weaknesses related to memory access, such as those identified by CWE-119 and its descendants. However, the term is not formal, and there is likely disagreement between practitioners as to which weaknesses are implicitly covered by the "memory safety" term. |
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Memory-Unsafe | Often |
| Language | C | Often |
| Language | C++ | Often |
| Language | Assembly | Undetermined |
| Technology | Not Technology-Specific | Undetermined |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Integrity, Confidentiality, Availability | Execute Unauthorized Code or Commands, Modify Memory | If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can alter the intended control flow by redirecting a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator. |
| Availability, Confidentiality | Read Memory, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory) | Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. |
| Confidentiality | Read Memory | In the case of an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffer's position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences. |
Potential Mitigations
| Phase | Description |
|---|---|
| Requirements | Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe. |
| 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. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions. |
| Operation, Build and Compilation | Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail. |
| Implementation | Consider adhering to the following rules when allocating and managing an application's memory: - Double check that the buffer is as large as specified. - When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. - Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. - If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions. |
| Operation, Build and Compilation | Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335]. |
| Operation | Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336]. |
| Implementation | Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available. |
CWE-158
Improper Neutralization of Null Byte or NUL Character
Status: Incomplete
Description
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Not Language-Specific | Undetermined |
| Language | C | Undetermined |
| Language | C++ | Undetermined |
| Technology | Not Technology-Specific | Undetermined |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Integrity | Unexpected State |
Potential Mitigations
| Phase | Description |
|---|---|
| Developers should anticipate that null characters or null bytes will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system. | |
| 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. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. |
| 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). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. |
Abstraction: Variant
| Referenced By CVEs: |
| CVE-2026-104286 |
CWE-177
Improper Handling of URL Encoding (Hex Encoding)
Status: Draft
Description
The product does not properly handle when all or part of an input has been URL encoded.
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Not Language-Specific | Undetermined |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Integrity | Unexpected State |
Potential Mitigations
| Phase | Description |
|---|---|
| Architecture and Design | Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. |
| 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. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. |
| 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). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. |
Abstraction: Variant
| Referenced By CVEs: |
| CVE-2026-76504 |
CWE-22
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Status: Stable
Description
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.
Diagram
Alternate Terms
| Term | Description |
|---|---|
| Path traversal | "Path traversal" is preferred over "directory traversal," but both terms are attack-focused. |
| Directory traversal | |
| Path transversal | an alternate phrasing of "path traversal" |
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Not Language-Specific | Undetermined |
| Technology | AI/ML | Often |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Integrity, Confidentiality, Availability | Execute Unauthorized Code or Commands | The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries. |
| Integrity | Modify Files or Directories | The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication. |
| Confidentiality | Read Files or Directories | The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system. |
| Availability | DoS: Crash, Exit, or Restart | The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of protection mechanisms such as authentication, it has the potential to lock out product users. |
Potential Mitigations
| Phase | Description |
|---|---|
| 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. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string. |
| 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. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. |
| 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). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: - realpath() in C - getCanonicalPath() in Java - GetFullPath() in ASP.NET - realpath() or abs_path() in Perl - realpath() in PHP |
| 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]. |
| Operation | Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481]. |
| Architecture and Design, Operation | Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations. |
| Architecture and Design | When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability. |
| Architecture and Design, Operation | Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails. |
| Architecture and Design, Operation | Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately. This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface. |
| Implementation | Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy. |
| Operation, Implementation | When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues. |
CWE-269
Improper Privilege Management
Status: Draft
Description
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Diagram
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Not Language-Specific | Undetermined |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Access Control | Gain Privileges or Assume Identity |
Potential Mitigations
| Phase | Description |
|---|---|
| Architecture and Design, Operation | Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software. |
| Architecture and Design | Follow the principle of least privilege when assigning access rights to entities in a software system. |
| Architecture and Design | Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource. |
CWE-384
Session Fixation
Status: Incomplete
Description
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Not Language-Specific | Undetermined |
| Technology | Web Based | Undetermined |
| Technology | Web Server | Undetermined |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Access Control | Gain Privileges or Assume Identity |
Potential Mitigations
| Phase | Description |
|---|---|
| Architecture and Design | Invalidate any existing session identifiers prior to authorizing a new user session. |
| Architecture and Design | For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again. |
| Operation | Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481]. |
Abstraction: Compound
| Referenced By CVEs: |
| CVE-2026-102489 |
CWE-787
Out-of-bounds Write
Status: Draft
Description
The product writes data past the end, or before the beginning, of the intended buffer.
Diagram
Alternate Terms
| Term | Description |
|---|---|
| Memory Corruption | Often used to describe the consequences of writing to memory outside the bounds of a buffer, or to memory that is otherwise invalid. |
Applicable Platforms
| Type | Name | Prevalence |
|---|---|---|
| Language | Memory-Unsafe | Often |
| Language | C | Often |
| Language | C++ | Often |
| Language | Assembly | Undetermined |
| Technology | ICS/OT | Often |
Common Consequences
| Scope | Impact | Note |
|---|---|---|
| Integrity | Modify Memory, Execute Unauthorized Code or Commands | Write operations could cause memory corruption. In some cases, an adversary can modify control data such as return addresses in order to execute unexpected code. |
| Availability | DoS: Crash, Exit, or Restart | Attempting to access out-of-range, invalid, or unauthorized memory could cause the product to crash. |
| Other | Unexpected State | Subsequent write operations can produce undefined or unexpected results. |
Potential Mitigations
| Phase | Description |
|---|---|
| Requirements | Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe. |
| 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. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions. |
| Operation, Build and Compilation | Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail. |
| Implementation | Consider adhering to the following rules when allocating and managing an application's memory: - Double check that the buffer is as large as specified. - When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. - Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. - If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions. |
| Operation, Build and Compilation | Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335]. |
| Operation | Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336]. |
| Implementation | Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available. |
