<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T07:57:30.131481+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-66021</id>
    <title>CVE-2025-66021 — OWASP Java HTML Sanitizer is vulnerable to XSS via noscript tag and improper style tag sanitization</title>
    <updated>2026-10-05T07:57:30.528371+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> OWASP java-html-sanitizer</p>
<p>OWASP Java HTML Sanitizer is a configureable HTML Sanitizer written in Java, allowing inclusion of HTML authored by third-parties in web applications while protecting against XSS. In version 20240325.1,  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. At time of publication no known patch is available.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-66021"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-mfg7-5gfp-c4w3</id>
    <title>GHSA-mfg7-5gfp-c4w3 — Netty: Memory Leak in DNS Record Decoder via Malformed Domain Names</title>
    <updated>2026-10-05T07:57:30.528435+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: io.netty:netty-codec-dns</p>
<p>### Summary
A memory leak can be caused in Netty's DNS codec by sending malicious DNS packets containing invalid domain names. Because the leak occurs incrementally per packet, sustained malicious requests will cause a gradual Denial of Service.</p>
<p>### Details
Inside `io.netty.handler.codec.dns.AbstractDnsRecord`, the parsed domain name string is passed to `IDN.toASCII(name)`. If the domain name contains characters that violate IDNA rules, `IDN.toASCII` throws an `IllegalArgumentException`.</p>
<p>Because this exception occurs inside the constructor before the `DnsRecord` instance can assign the buffer to its content field for later release, the ByteBuf whose reference count was incremented (or newly allocated) is never released, resulting in a direct memory leak.</p>
<p>There are several places where variants of this leak happen:
- `io.netty.handler.codec.dns.DefaultDnsRecordDecoder#decodeRecord(java.lang.String, io.netty.handler.codec.dns.DnsRecordType, int, long, io.netty.buffer.ByteBuf, int, int)` invokes `in.retainedDuplicate()` or creates a new buffer `out` when constructing `DefaultDnsRawRecord`
- `io.netty.handler.codec.dns.DnsCodecUtil#decompressDomainName` allocates a new `ByteBuf` and passes it to `encodeDomainName()`. If the decompressed domain name contains a null byte (`\0`), `encodeDomainName()` throws an `IllegalArgumentException`, leaking the newly allocated buffer.</p>
<p>### Impact
Resource Exhaustion. Any application utilizing Netty's DnsRecordDecoder (such as DnsNameResolve…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-mfg7-5gfp-c4w3"/>
  </entry>
</feed>
