%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%% %%%%%%%%%%% %%%%%%%%%%% CWE DETAILED CONTENT SUBMISSION FORM %%%%%%%%%%% %%%%%%%%%%% %%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Please use this form to submit additional details to new CWE content suggestions that have already been approved by the CWE team for development into a new entry. Initial content suggestions should be submitted via the more lightweight CWE Content Web Submission Form. All new content submissions must adhere to the Terms of Use (see below). In addition to the instructions provided below, please review the Guidelines for New Content Suggestions located on the CWE website. (https://cwe.mitre.org/community/submissions/overview.html) This form is meant as a starting point to submit fundamental weakness information to the CWE corpus. Depending on the weakness type, this form may not cover all CWE fields that may ultimately be needed before publication. Additional correspondence with the CWE team may be necessary. For a complete list of information fields available, please review the CWE Schema. (https://cwe.mitre.org/documents/schema/) POINT OF CONTACT ----------------- CWE Team The MITRE Corporation 202 Burlington Road Bedford, MA, USA 01730-1420 cwe@mitre.org TERMS OF USE CWE(TM) is free to use by any organization or individual for any research, development, and/or commercial purposes, per these CWE Terms of Use. The MITRE Corporation ("MITRE") has copyrighted the CWE List, Top 25, CWSS, and CWRAF for the benefit of the community in order to ensure each remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. CWE is a trademark of MITRE. Please contact cwe@mitre.org if you require further clarification on this issue. LICENSE CWE Submissions: By submitting materials to The MITRE Corporation's ("MITRE") Common Weakness Enumeration Program (CWE(TM)), you hereby grant to MITRE a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your submitted materials and derivative works. Unless otherwise required by applicable law or agreed to in writing, it is understood that you are providing such materials on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. CWE Usage: MITRE hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE's copyright designation and this license in any such copy. DISCLAIMERS ALL DOCUMENTS AND THE INFORMATION CONTAINED IN THE CWE ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, OFFICERS, AGENTS, AND EMPLOYEES BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE INFORMATION OR THE USE OR OTHER DEALINGS IN THE CWE. Last updated: February 14, 2022 PROCESS ------------- 1) Ensure the following before submitting content: a. Information is Public. The submitted information, if included within CWE, will become public information. Ensure that the information has been approved for public release by the appropriate authority. b. Conformance to Guidelines. It is your option regarding how closely you want to conform with these guidelines. However, submissions that do not follow these guidelines may take longer to integrate into CWE, or they may be modified heavily. Generally, The CWE team may choose to de-prioritize non-conformant submissions. c. Abstraction. Consider whether the submission is at an appropriate level of abstraction that is represented within CWE. Guidelines are not well-defined as of this time, but be familiar with Classes, Bases, and Variants (from the schema or glossary, and from reviewing existing CWE content). Generally, The CWE team prefers submissions at the Base level; however, you might only be aware of a weakness at a lower Variant level. d. Scope. Ensure that the submission is within the scope of CWE. When uncertain, you can consult with The CWE team about this. e. Advanced Notice. Contact the CWE Team at cwe@mitre.org and provide a name and short description of the weakness you would like to submit. This is to avoid time wasted on something that may already exist or is being worked on by someone else. 2) Complete the "Submitter's Information" and "New CWE Content Information" sections below. 3) Email your form to cwe@mitre.org. 4) We will work with you to ensure that the information is complete. 5) If the CWE team is considering a significant change to your entry after publication, the team will attempt to contact you to discuss those change requests / modifications before they are released. Modifications that would alter the underlying meaning of the CWE would result in deprecation (and the subsequent creation of a new CWE) enabling the long-term viability of the original CWE. ************************************************************************************************ SUBMITTER'S INFORMATION The following information will be used for attributing the CWE entry to the correct submitting party. Please provide the requested information exactly as you wish it to appear at the bottom of weakness entries on the CWE site. ************************************************************************************************ Email your completed form to cwe@mitre.org. 1) CONTACT INFORMATION ---------------------------- A) YOUR NAME (required): <> B) YOUR EMAIL (required): <> 2) NAME OF YOUR ORGANIZATION ---------------------------- A) YOUR ORGANIZATION (required, please provide in exactly the format it should appear on our site): <> 3) TODAY'S DATE ---------------------------- <> ************************************************************************************************ NEW CWE CONTENT INFORMATION For further guidance and information on the ideal information to be provided on this form, please see the Guidelines for New Content Suggestions (https://cwe.mitre.org/community/submissions/overview.html) as well as the CWE Glossary (https://cwe.mitre.org/documents/glossary/index.html), Vulnerability Theory (https://cwe.mitre.org/documents/vulnerability_theory/intro.html), and Schema (https://cwe.mitre.org/documents/schema/). ************************************************************************************************ 1. ENTRY NAME (required) Ideally, the suggested name should include: (1) the intended behavior of the code, (2) the mistake (i.e. weakness), (3) the affected resource (if relevant), and (4) the affected technology (if relevant). Ex: Instead of "SQL Injection," use "Improper Neutralization of Special Elements used in an SQL Command" <> 2. SUMMARY (required) The summary consists of only one or two sentences that describe the weakness itself, i.e. the mistake that is made. <> 3. EXTENDED DESCRIPTION (required) The extended description provides additional explanation for the weakness. Generally, the intended audience is a developer/designer who might not immediately understand how the weakness can be a problem, or who may have an overly simplistic understanding of the problem. <> 4. MODES OF INTRODUCTION (required) This provides information about how and when a given weakness may be introduced. Your entry should consist of a Phase. A descriptive Note is optional. +---------+-----------------------------------------+ | Element | Description | +---------+-----------------------------------------+ | Phase | <> | | Note | (optional) <> | +---------+-----------------------------------------+ Phase enumeration: Policy, Requirements, Architecture and Design, Implementation, Build and Compilation, Testing, Documentation, Bundling, Distribution, Installation, System Configuration, Operation, Patching and Maintenance, Porting, Integration, and Manufacturing 5. POTENTIAL MITIGATIONS (required) This element should cover one or more techniques that will eliminate and/or reduce the frequency or impact of the weakness. Your entry should include a Phase and Description, while the Effectiveness element is optional. A descriptive Note is also optional. +---------------------+------------------------------------------+ | Element | Description | +---------------------+------------------------------------------+ | Phase | <> | | Description | <> | | Effectiveness | (optional) << put the information here>> | | Effectiveness Notes | (optional) <> | +---------------------+------------------------------------------+ Phase enumeration: Policy, Requirements, Architecture and Design, Implementation, Build and Compilation, Testing, Documentation, Bundling, Distribution, Installation, System Configuration, Operation, Patching and Maintenance, Porting, Integration, and Manufacturing Effectiveness enumeration: High, Moderate, Limited, Incidental, Defense in Depth 6. COMMON CONSEQUENCES (required) This element will cover the typical negative security impact (or impacts) that occurs if this weakness can be exploited by an attacker. Your entry should include Scope and Impact, while the Likelihood element is optional. A descriptive Note is also optional. +------------+------------------------------------------+ | Element | Description | +------------+------------------------------------------+ | Scope | <> | | Impact | <> | | Likelihood | (optional) << put the information here>> | | Note | (optional) <> | +------------+------------------------------------------+ Scope enumeration: Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation, and Other Impact: Modify memory, Read Memory, Modify Files or Directories, Read Files or Directories, Modify Application Data, Read Application Data, DoS: Crash, Exit, or Restart, DoS: Amplification, DoS: Instability, DoS: Resource Consumption (e.g., CPU, Memory, Other), Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Hide Activities, Alter Execution Logic, Quality Degradation, Unexpected State, Varies by Context, Reduce Maintainability, Reduce Performance, Reduce Reliability, Other Likelihood enumeration: High, Medium, Low 7. APPLICABLE PLATFORMS (required) This element specifies the programming languages, operating systems, architectures, and technologies in which this weakness is usually found. Your entry should include either a Name(s) or Class for each element, but not both. +------------------+-------------------------------------+ | Element | Description | +------------------+-------------------------------------+ | Language | Name: <> | | | Class: <> | | | | | Operating System | Name: <> | | | Class: <> | | | | | Architecture | Name: <> | | | Class: <> | | | | | Technology | Name: <> | | | Class: <> | +------------------+-------------------------------------+ Language Name: Ada, ASP, ASP.NET, Basic, C, COBOL, C++, C#, Fortran, F#, HTML, Java, Javascript, JSP, Objective-C, Pascal, Perl, PHP, Python, Ruby, SQL, Shell, Swift, VB.Net, XML, Other Language Class: Assembly, Compiled, Interpreted, Language-Independent Operating System Name: AIX, Android, Blackberry OS, Chrome OS, Darwin, FreeBSD, iOS, macOS, NetBSD, OpenBSD, Red Hat, Solaris, SUSE, tvOS, Ubuntu, watchOS, Windows 9x, Windows Embedded, Windows NT Operating System Class: Linux, macOS, Unix, Windows, OS-Independent Architecture Name: Alpha, ARM, Itanium, Power Architecture, SPARC, x86, Other Architecture Class: Embedded, Microcomputer, Workstation, Architecture-Independent Technology Name: Web Server, Database Servcer, Accelerator IP, Analog and Mixed Signal IP, Audio/Video IP, Bus/Interface IP, Clock/Counter IP, Communication IP, Controller IP, Memory IP, Microcontroller IP, Network on Chip IP, Power Managemnt IP, Processor IP, Security IP, Sensor IP, Storage IP, Test/Debug IP, Other Technology Class: Client Server, Cloud Computing, Mainframe, Mobile, N-Tier, SOA, System on Chip, Web Based, Technology-Independent 8. DEMONSTRATIVE EXAMPLES (required) The entry should have one or more demonstrative examples, but submitters should not put significant effort into these until the CWE team has reviewed and accepted the general concepts behind the submission. Submissions can include example information for either Software, Hardware, or both, as relevant. +---------------------------------------------+------------------------------+ | Element | Description | +---------------------------------------------+------------------------------+ | Introductory Text | <> | | | | | "Bad" Code Snippets or Descriptive Example | <> | | | | | Explanatory Text | <> | | | | | "Good" Code Snippets or Descriptive Example | <> | +---------------------------------------------+------------------------------+ * If you would like to submit diagrams to support your hardware weakness descriptive examples, please attach it to the email submission in a png format and reference it by filename where desired. For an example, please see: https://cwe.mitre.org/data/definitions/1256.html 9. OBSERVED EXAMPLES (recommended, if possible) Where known, the submission should identify multiple publicly-reported vulnerabilities in real-world software that exhibit the weakness. If possible, include CVE Identifier, its corresponding weblink, and a short summary. +----------------+------------------------------+ | Element | Description | +----------------+------------------------------+ | CVE Identifier | <> | | Link | <> | | Summary | <> | +----------------+------------------------------+ 10. RELATIONSHIPS (recommended) Identify the parent CWE(s) under which this weakness should be classified. Ensure that these parents are Weakness types, not categories. The CWE team will perform additional analysis to ensure that the appropriate relationships exist. <> 11. REFERENCES (recommended) References can include one or more academic papers, white papers, blog posts, slide presentations, or videos that describe the weakness, with URLs. +-----------+------------------------------+ | Element | Description | +-----------+------------------------------+ | URL | <> | | Title | <> | | Author(s) | <> | +-----------+------------------------------+