dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection vulnerability in Class: Element. Methods: addElement, addAttribute th…
dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection vulnerability in Class: Element. Methods: addElement, addAttribute that can result in an attacker tampering with XML documents through XML injection. This attack appear to be exploitable via an attacker specifying attributes or elements in the XML document. This vulnerability appears to have been fixed in 2.1.1 or later.
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
https://cwe.mitre.org/data/definitions/88.html →Open in CWE collection →The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
https://cwe.mitre.org/data/definitions/91.html →Open in CWE collection →This type of attack involves an attacker leveraging meta-characters in email headers to inject improper behavior into email programs. Email software has become increasingly sophisticated and feature-rich. In addition, email applications are ubiquitous and connected directly to the Web making them ideal targets to launch and propagate attacks. As the user demand for new functionality in email applications grows, they become more like browsers with complex rendering and plug in routines. As more email functionality is included and abstracted from the user, this creates opportunities for attackers. Virtually all email applications do not list email header information by default, however the email header contains valuable attacker vectors for the attacker to exploit particularly if the behavior of the email client application is known. Meta-characters are hidden from the user, but can contain scripts, enumerations, probes, and other attacks against the user's system.
https://capec.mitre.org/data/definitions/41.html →Open in CAPEC collection →An attacker can craft special user-controllable input consisting of XPath expressions to inject the XML database and bypass authentication or glean information that they normally would not be able to. XPath Injection enables an attacker to talk directly to the XML database, thus bypassing the application completely. XPath Injection results from the failure of an application to properly sanitize input used as part of dynamic XPath expressions used to query an XML database.
https://capec.mitre.org/data/definitions/83.html →Open in CAPEC collection →In this type of an attack, an adversary injects operating system commands into existing application functions. An application that uses untrusted input to build command strings is vulnerable. An adversary can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system.
https://capec.mitre.org/data/definitions/88.html →Open in CAPEC collection →An adversary manipulates the content of request parameters for the purpose of undermining the security of the target. Some parameter encodings use text characters as separators. For example, parameters in a HTTP GET message are encoded as name-value pairs separated by an ampersand (&). If an attacker can supply text strings that are used to fill in these parameters, then they can inject special characters used in the encoding scheme to add or modify parameters. For example, if user input is fed directly into an HTTP GET request and the user provides the value "myInput&new_param=myValue", then the input parameter is set to myInput, but a new parameter (new_param) is also added with a value of myValue. This can significantly change the meaning of the query that is processed by the server. Any encoding scheme where parameters are identified and separated by text characters is potentially vulnerable to this attack - the HTTP GET encoding used above is just one example.
https://capec.mitre.org/data/definitions/137.html →Open in CAPEC collection →An adversary takes advantage of improper data validation to inject malicious global parameters into a Flash file embedded within an HTML document. Flash files can leverage user-submitted data to configure the Flash document and access the embedding HTML document.
https://capec.mitre.org/data/definitions/174.html →Open in CAPEC collection →An attacker utilizes crafted XML user-controllable input to probe, attack, and inject data into the XML database, using techniques similar to SQL injection. The user-controllable input can allow for unauthorized viewing of data, bypassing authentication or the front-end application for direct XML database access, and possibly altering database information.
https://capec.mitre.org/data/definitions/250.html →Open in CAPEC collection →An adversary adds duplicate HTTP GET/POST parameters by injecting query string delimiters. Via HPP it may be possible to override existing hardcoded HTTP parameters, modify the application behaviors, access and, potentially exploit, uncontrollable variables, and bypass input validation checkpoints and WAF rules.
https://capec.mitre.org/data/definitions/460.html →Open in CAPEC collection →| Product | Vendor | Status |
|---|---|---|
| ansible-runner | Tracked | |
| ansible-runner | Tracked | |
| ansiblerole-foreman_scap_client | Tracked | |
| ansiblerole-foreman_scap_client | Tracked | |
| ansiblerole-insights-client | Tracked | |
| ansiblerole-insights-client | Tracked | |
| apache-cxf | Tracked | |
| apache-cxf | Tracked | |
| apache-cxf | Tracked | |
| candlepin | Tracked | |
| candlepin | Tracked | |
| createrepo_c | Tracked | |
| createrepo_c | Tracked | |
| dom4j | Tracked | |
| dom4j | Tracked | |
| dom4j | Tracked | |
| dom4j | Tracked | |
| dom4j | Tracked | |
| dom4j | Tracked | |
| dom4j | Tracked |