CWE-96
AllowedImproper Neutralization of Directives in Statically Saved Code ('Static Code Injection')
Abstraction: Base · Status: Draft
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
43 vulnerabilities reference this CWE, most recent first.
GHSA-WCG9-PGQV-XM5V
Vulnerability from github – Published: 2024-08-19 21:49 – Updated: 2024-08-19 21:49Impact
Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript. This requires social engineer to trick a user to follow the URL.
Reproduction steps
- As a user without script or programming right, create a (non-terminal) document named
" + alert(1) + "(the quotes need to be part of the name). - Edit the class.
- Add a string property named
"test". - Edit using the object editor and add an object of the created class
- Get an admin to open
<xwiki-server>/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=editwhere<xwiki-server>is the URL of your XWiki installation.
Patches
This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.
Workarounds
We're not aware of any workaround except upgrading.
References
- https://jira.xwiki.org/browse/XWIKI-21810
- https://github.com/xwiki/xwiki-platform/commit/27eca8423fc1ad177518077a733076821268509c
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.2"
},
{
"fixed": "14.10.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "15.6-rc-1"
},
{
"fixed": "15.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0-rc-1"
},
{
"fixed": "16.0.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"16.0.0-rc-1"
]
}
],
"aliases": [
"CVE-2024-43400"
],
"database_specific": {
"cwe_ids": [
"CWE-79",
"CWE-96"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-19T21:49:07Z",
"nvd_published_at": "2024-08-19T17:15:09Z",
"severity": "CRITICAL"
},
"details": "### Impact\nIs it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript.\nThis requires social engineer to trick a user to follow the URL.\n\n#### Reproduction steps\n\n1. As a user without script or programming right, create a (non-terminal) document named `\" + alert(1) + \"` (the quotes need to be part of the name).\n1. Edit the class.\n1. Add a string property named `\"test\"`.\n1. Edit using the object editor and add an object of the created class\n1. Get an admin to open `\u003cxwiki-server\u003e/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display\u0026type=object\u0026property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test\u0026mode=edit` where `\u003cxwiki-server\u003e` is the URL of your XWiki installation.\n\n### Patches\nThis has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.\n\n### Workarounds\n\nWe\u0027re not aware of any workaround except upgrading.\n\n### References\n- https://jira.xwiki.org/browse/XWIKI-21810\n- https://github.com/xwiki/xwiki-platform/commit/27eca8423fc1ad177518077a733076821268509c\n",
"id": "GHSA-wcg9-pgqv-xm5v",
"modified": "2024-08-19T21:49:07Z",
"published": "2024-08-19T21:49:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-wcg9-pgqv-xm5v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43400"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/27eca8423fc1ad177518077a733076821268509c"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-21810"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "XWiki Platform allows XSS through XClass name in string properties"
}
GHSA-WF3X-JCCF-5G5G
Vulnerability from github – Published: 2024-07-31 15:21 – Updated: 2024-11-18 16:26Impact
When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment.
In order to reproduce, as any user, create a file named "><img src=1 onerror=alert(1)>.jpg. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display "1", then the instance is vulnerable.
Patches
This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.
Workarounds
We're not aware of any workaround except upgrading.
References
- https://jira.xwiki.org/browse/XWIKI-19611
- https://jira.xwiki.org/browse/XWIKI-21769
- https://jira.xwiki.org/browse/XWIKI-19602
- https://github.com/xwiki/xwiki-platform/commit/910a5018a50039e8b24556573dfe342f143ef949
Attribution
This vulnerability has been independently reported by Aleksey Solovev (Positive Technologies) and Georgios Roumeliotis for TwelveSec.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-war"
},
"ranges": [
{
"events": [
{
"introduced": "4.2-milestone-3"
},
{
"fixed": "14.10.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-war"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-war"
},
"ranges": [
{
"events": [
{
"introduced": "15.6-rc-1"
},
{
"fixed": "15.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-web-war"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0-rc-1"
},
{
"fixed": "16.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-37900"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-96"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-31T15:21:06Z",
"nvd_published_at": "2024-07-31T16:15:03Z",
"severity": "HIGH"
},
"details": "### Impact\nWhen uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn\u0027t notice the malicious filename while uploading the attachment.\n\nIn order to reproduce, as any user, create a file named `\"\u003e\u003cimg src=1 onerror=alert(1)\u003e.jpg`. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display \"1\", then the instance is vulnerable.\n\n### Patches\nThis has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.\n\n### Workarounds\nWe\u0027re not aware of any workaround except upgrading.\n\n### References\n* https://jira.xwiki.org/browse/XWIKI-19611\n* https://jira.xwiki.org/browse/XWIKI-21769\n* https://jira.xwiki.org/browse/XWIKI-19602\n* https://github.com/xwiki/xwiki-platform/commit/910a5018a50039e8b24556573dfe342f143ef949\n\n### Attribution\n\nThis vulnerability has been independently reported by Aleksey Solovev (Positive Technologies) and Georgios Roumeliotis for TwelveSec.",
"id": "GHSA-wf3x-jccf-5g5g",
"modified": "2024-11-18T16:26:57Z",
"published": "2024-07-31T15:21:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-wf3x-jccf-5g5g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37900"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/6cdd69d31d6bf3caa7f40ec55eb317e4e528ad28"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/8b8a2d80529b9a9c038014c1eb6c2adc08069dfd"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/910a5018a50039e8b24556573dfe342f143ef949"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/9df46f8e5313af46f93bccd1ebc682e28126573f"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19602"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19611"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-21769"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "XWiki Platform vulnerable to Cross-site Scripting through attachment filename in uploader"
}
GHSA-X28W-HVWC-MP75
Vulnerability from github – Published: 2022-03-11 00:02 – Updated: 2022-03-25 17:18Microweber is a new generation CMS with drag and drop. Prior to version 1.3, Microweber is vulnerable to static code injection.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "microweber/microweber"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-0895"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-96"
],
"github_reviewed": true,
"github_reviewed_at": "2022-03-11T20:28:04Z",
"nvd_published_at": "2022-03-10T11:15:00Z",
"severity": "HIGH"
},
"details": "Microweber is a new generation CMS with drag and drop. Prior to version 1.3, Microweber is vulnerable to static code injection.",
"id": "GHSA-x28w-hvwc-mp75",
"modified": "2022-03-25T17:18:05Z",
"published": "2022-03-11T00:02:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0895"
},
{
"type": "WEB",
"url": "https://github.com/microweber/microweber/commit/b2baab6e582b2efe63788d367a2bb61a2fa26470"
},
{
"type": "PACKAGE",
"url": "https://github.com/microweber/microweber"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/3c070828-fd00-476c-be33-9c877172363d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "Static Code Injection in Microweber"
}
Mitigation MIT-5
Strategy: Input Validation
- 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.
Mitigation
Strategy: Output Encoding
Perform proper output validation and escaping to neutralize all code syntax from data written to code files.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.