Search
Search Results (5 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-54571 | 1 Owasp | 1 Modsecurity | 2025-11-03 | 6.1 Medium |
| ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. In versions 2.9.11 and below, an attacker can override the HTTP response’s Content-Type, which could lead to several issues depending on the HTTP scenario. For example, we have demonstrated the potential for XSS and arbitrary script source code disclosure in the latest version of mod_security2. This issue is fixed in version 2.9.12. | ||||
| CVE-2018-13065 | 1 Owasp | 1 Modsecurity | 2025-07-03 | N/A |
| ModSecurity 3.0.0 has XSS via an onerror attribute of an IMG element. NOTE: a third party has disputed this issue because it may only apply to environments without a Core Rule Set configured | ||||
| CVE-2019-19886 | 2 Fedoraproject, Owasp | 2 Fedora, Modsecurity | 2025-07-03 | 7.5 High |
| Trustwave ModSecurity 3.0.0 through 3.0.3 allows an attacker to send crafted requests that may, when sent quickly in large volumes, lead to the server becoming slow or unresponsive (Denial of Service) because of a flaw in Transaction::addRequestHeader in transaction.cc. | ||||
| CVE-2019-25043 | 1 Owasp | 1 Modsecurity | 2025-07-03 | 5.3 Medium |
| ModSecurity 3.x before 3.0.4 mishandles key-value pair parsing, as demonstrated by a "string index out of range" error and worker-process crash for a "Cookie: =abc" header. | ||||
| CVE-2020-15598 | 2 Debian, Owasp | 2 Debian Linux, Modsecurity | 2025-07-03 | 7.5 High |
| Trustwave ModSecurity 3.x through 3.0.4 allows denial of service via a special request. NOTE: The discoverer reports "Trustwave has signaled they are disputing our claims." The CVE suggests that there is a security issue with how ModSecurity handles regular expressions that can result in a Denial of Service condition. The vendor does not consider this as a security issue because1) there is no default configuration issue here. An attacker would need to know that a rule using a potentially problematic regular expression was in place, 2) the attacker would need to know the basic nature of the regular expression itself to exploit any resource issues. It's well known that regular expression usage can be taxing on system resources regardless of the use case. It is up to the administrator to decide on when it is appropriate to trade resources for potential security benefit | ||||
Page 1 of 1.