Apache CXF's EndpointReferenceUtils and W3CMultiSchemaFactory classes construct a SAXParserFactory without the necessary JAXP hardening configurations, enabling out-of-band (OOB) external entity resolution. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fix this issue.
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix use-after-free in VEPA multicast source pruning
ixgbevfcleanrxirq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:
devkfreeskbirq(skb); continue;
The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevfaddrxfrag() on the freed skb, dereferencing skbshinfo(skb)->nrfrags - a use-after-free in NAPI softirq context.
The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.
I do not have ixgbevf hardware; the bug was found by static analysis (scandropcontinueloops.py + semgrep dropcontinueinloop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfreeskb, then read skbshinfo(skb)->nrfrags):
BUG: KASAN: slab-use-after-free in ixgbevfuaftestinit+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)
QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.
In the Linux kernel, the following vulnerability has been resolved:
net: slip: serialize receive against buffer reallocation
slreallocbufs() replaces rbuff and updates buffsize while holding sl->lock. slipreceivebuf() reads those fields and writes through rbuff without holding the lock.
An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed.
Serialize receive processing with slreallocbufs() by holding sl->lock while consuming each receive batch.
In the Linux kernel, the following vulnerability has been resolved:
sctp: auth: verify auth requirement when authchunk is NULL
sctpauthchunkverify() returns true unconditionally when chunk->authchunk is NULL, silently skipping authentication. This is incorrect when:
1. skbclone() failed in the BH receive path, leaving authchunk NULL. In sctpendpointbhrcv() asoc is NULL for new connections, so the early sctpauthrecvcid() check cannot catch this.
2. No AUTH chunk precedes COOKIE-ECHO, so skbclone() is never called and authchunk remains NULL.
Fix by checking sctpauthrecvcid() when authchunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: handle inline data with a nonzero offset
nvmetrdmauseinlinesg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inlinedatasize, but the mapping still assumes the data begins in the first inline page:
sg->offset = off; sg->length = mint(int, len, PAGESIZE - off);
When a port is configured with inlinedatasize > PAGESIZE (settable up to max(SZ16K, PAGESIZE)), an offset in (PAGESIZE, inlinedatasize] makes "PAGESIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. numpages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.
Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from pageoff + len. Because the request scatterlist may now start at inlinesg[pageidx] rather than inlinesg[0], generalize the inline-SGL identity test in nvmetrdmareleasersp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmetreqfreesgls() frees an inline page (and warns in freelargekmalloc()).
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: stop fast-leave after deleting a port group
brmulticastleavegroup() iterates mp->ports with pp = &p->next in its fast-leave path. After brmulticastdelpg() removes p, continuing the loop advances pp through the deleted entry.
If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, brportgroupequal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group.
Fast leave only needs to remove one matching port group. Break after brmulticastdelpg() so the loop stops before dereferencing the removed entry.
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsitcp: Bound SCSI Response data segment to the connection buffer
iscsitcphdrdissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSIDEFMAXRECVSEGLEN (8192) bytes. For the LOGINRSP, TEXTRSP, REJECT and ASYNCEVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer.
The SCSI Command Response (ISCSIOPSCSICMDRSP) path also copies its data segment (sense/response data) into conn->data via iscsitcpdatarecvprep(), but it does so without the same check. The only upstream bound on in.datalen is conn->maxrecvdlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and maxrecvdlength therefore overflows the 8192-byte conn->data buffer.
Once the same bound applies, ISCSIOPSCSICMDRSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.
wkhtmlTOpdf 0.12.6 is vulnerable to SSRF which allows an attacker to get initial access into the target's system by injecting iframe tag with initial asset IP address on it's source. This allows the attacker to takeover the whole infrastructure by accessing their internal assets.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix stale skb->prev after async crypto steals a GSO segment
skbgsosegment() leaves the segment list head with ->prev pointing at the last segment, an invariant validatexmitskblist() relies on when it sets its tail pointer (tail = skb->prev).
When validatexmitxfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validatexmitskblist() later does tail->next = skb, writing through that stale pointer -- a use-after-free.
Repoint skb->prev at the last retained segment before returning.
In the Linux kernel, the following vulnerability has been resolved:
Path traversal vulnerability in Apache FreeMarker template loading mechanism, if the attacker can specify an arbitrary malformed locale identifier to FreeMarker, and the localized lookup configuration setting is enabled (it's by default enabled).
This issue affects Apache FreeMarker from 2.2.0 through 2.3.34.
Users are recommended to upgrade to version 2.3.35. Disabling localized lookup in previous versions also mitigates this.
Note that even in versions affected by this vulnerability, the files that can be loaded remain restricted by the TemplateLoader that FreeMarker is configured to use. In particular, FileTemplateLoader prevents attempts to traverse outside the baseDir specified in its constructor. Other TemplateLoader implementations may allow access outside their designated base directory, but they are still constrained by the underlying storage mechanism—for example, a loader wrapping a Java class loader can only access resources that the class loader can load, while one wrapping a web application context can only access resources available through that context.
Integer wraparound in PostgreSQL 32-bit builds of pltcl and plperl allows an object creator to cause the server to undersize an allocation and write out-of-bounds via crafted function bodies. This may execute arbitrary code as the operating system user running the database. CVE-2026-6473 had fixed similar problems. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
PostgreSQL type confusion in cursor CLOSE + DECLARE executes arbitrary code
PostgreSQL refint plan cache type confusion executes arbitrary code
Heap buffer overflow in PostgreSQL regexp allows the query author to execute arbitrary code as the operating system user running the database, via text that would not pass encoding validation. This shares heritage with CVE-2026-2006, but this case involved unanticipated data growth when round-tripped through pgwchar. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Integer wraparound in PostgreSQL fuzzystrmatch allows a user to direct writes to a huge range of addresses, executing arbitrary code as the operating system user running the database, via extreme inputs to SQL function levenshtein() or levenshteinlessequal(). Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Heap buffer overflow in PostgreSQL tochar(timestamptz) allows the party choosing the timezone to execute arbitrary code as the operating system user running the database, via a long POSIX timezone abbreviation. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
PostgreSQL type confusion via "internal" arguments
PostgreSQL expression deparse allows SQL injection via EXTRACT argument
Integer wraparound in PostgreSQL tsvector and tsquery data type functions allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds, via crafted large inputs. This may execute arbitrary code as the operating system user running the database. These types are typically sourced from application logic, not taken from the application's user. Hence, application users attacking the database, through the application as a conduit, are unlikely. CVE-2026-6473 had fixed similar problems. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Heap buffer overflow in PostgreSQL plperl return of a tied hash allows the function owner to execute arbitrary code as the operating system user running the database, via a crafted function body. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
PostgreSQL psql \unrestrict lets superuser of pgdump origin server execute arbitrary code in psql client
Heap buffer overflow in PostgreSQL pgdump of long function transform lists allows an object creator to execute arbitrary code as the operating system user running pgdump, via a crafted transform list. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
IB/isert: Reject login PDUs shorter than ISERHEADERSLEN
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: reject oversized EMA RNR lists
nl80211parsernrelems() stores the parsed element count in a u8-backed cfg80211rnrelems::cnt field and uses that count to size the flexible array allocation.
Reject nested NL80211ATTREMARNRELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211parsembssidelems().
In the Linux kernel, the following vulnerability has been resolved:
ip6: vti: Use ip6tnl.net in vti6changelink().
ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6test netns ns2 ip -n ns2 link set vti6test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376!
Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIFFNETNSLOCAL from vti6 devices. A vti6 tunnel can then move through IFLANETNSFD. After the move devnet(dev) points at the new netns while t->net stays at the creation netns.
vti6changelink() and vti6update() still use devnet(dev) and devnet(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanupnet() of that netns later walks freed memory.
Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.
lxmlhtmlclean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href)
Reporter: Guillem Lefait <guillem@datamq.com> · Date: 2026-05-10 Affected: lxml ≤ 6.1.0 and lxmlhtmlclean ≤ 0.4.4 (latest stable) Confirmed against: lxml 6.1.0 + lxmlhtmlclean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 — bug is in pure-Python sanitizer logic, independent of the libxml2 backend) Root-cause class: same as CVE-2021-28957 (formaction missing from linkattrs)
Summary
Cleaner filters URL schemes (javascript:, vbscript:, …) by walking links via rewritelinks(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.linkattrs. That allow-list contains no prefixed names (xlink:href) and no srcset. As a result, when Cleaner is configured with safeattrsonly=False — a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing — <a xlink:href="javascript:…"> survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.
CWE: CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.
Affected components
| Package | Versions tested | File / line | |--------------------|------------------------|----------------------------------| | lxml | 4.9.x, 5.2.1, 6.1.0 | src/lxml/html/defs.py:20 | | lxml | " | src/lxml/html/init.py:485-528 | | lxmlhtmlclean | 0.4.0 – 0.4.4 | lxmlhtmlclean/clean.py:348,576 |
The legacy lxml.html.clean module — bundled in lxml < 5.2.0 and still installable on newer versions via the lxml[htmlclean] extra — shares the same bug.
Root cause
defs.linkattrs is a flat string set; the literal xlink:href is absent:
python lxml/html/defs.py linkattrs = frozenset([ 'action', 'archive', 'background', 'cite', 'classid', 'codebase', 'data', 'href', 'longdesc', 'profile', 'src', 'usemap', 'dynsrc', 'lowsrc', 'formaction', ])
HtmlMixin.iterlinks() (lxml/html/init.py:526-528) only yields attributes whose key is in that set:
python for attrib in linkattrs: if attrib in attribs: yield (el, attrib, attribs[attrib], 0)
Cleaner.call registers the URL-scheme filter via rewritelinks (lxmlhtmlclean/clean.py:348), which is a thin wrapper around iterlinks(). Because xlink:href is never yielded, removejavascriptlink (clean.py:576) is never invoked for it.
Minimal reproducer
python from lxml import html from lxmlhtmlclean import Cleaner
for payload in ( '<svg><a xlink:href="javascript:alert(1)">x</a></svg>', '<math><a xlink:href="javascript:alert(2)">y</a></math>', ): tree = html.fromstring(payload) Cleaner(safeattrsonly=False)(tree) print(html.tostring(tree).decode()) print(' iterlinks:', list(html.fromstring(payload).iterlinks())) <svg><a xlink:href="javascript:alert(1)">x</a></svg> ← unchanged iterlinks: [] ← link rewriter blind <math><a xlink:href="javascript:alert(2)">y</a></math> ← unchanged iterlinks: [] ← link rewriter blind
Both SVG and MathML scopes are vulnerable — same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (JaVaScRiPt:), HTML-entity (javascript:), embedded tab (java\tscript:).
Impact
A caller that uses Cleaner to neutralise untrusted HTML and chooses safeattrsonly=False — typically because the application wants to allow custom data-/aria-/vendor attributes — will silently pass javascript: payloads carried on xlink:href through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the safeattrsonly=False toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.
Suggested fix
Extend linkattrs to include xlink:href. In HTML mode, lxml.html keeps prefixed attribute names verbatim — the parsed key is the literal string xlink:href, not a Clark-notation form — so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:
diff # lxml/html/defs.py linkattrs = frozenset([ 'action', 'archive', 'background', 'cite', 'classid', 'codebase', 'data', 'href', 'longdesc', 'profile', 'src', 'usemap', 'dynsrc', 'lowsrc', 'formaction', + 'xlink:href', ])
This single change closes the reported XSS for both SVG <a xlink:href> and MathML <a xlink:href>. lxmlhtmlclean is the canonical home of the Cleaner code (881 lines); lxml.html.clean is a 21-line backward-compat shim (from lxmlhtmlclean import ) that picks up the fix automatically once linkattrs is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in lxmlhtmlclean is preferred.
Alternative (in-package fix, no lxml coordination needed): add a namespaced-URL-attribute walk inside Cleaner.call so the URL-scheme filter doesn't depend on linkattrs. Sketch:
python lxmlhtmlclean/clean.py — supplements rewritelinks() in call NSURLATTRS = ('xlink:href',) # extend as needed BADSCHEME = re.compile(r'^\s(javascript|vbscript|data):', re.I)
for el in doc.iter(): for attr in NSURLATTRS: if attr in el.attrib and BADSCHEME.match(el.attrib[attr]): del el.attrib[attr]
This decouples the cleaner from the upstream linkattrs set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.
Defense in depth (optional, regardless of which fix path is taken): - Also handle srcset: the value is a url 1x, url 2x, … descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap. - Also accept Clark-notation forms ({http://www.w3.org/1999/xlink}href) so XML-mode callers using lxml.etree get the same protection. HTML mode never produces this form, so not needed for the reported bug.
Severity
CVSS 3.1 base score: 8.2 / High — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (→ 7.6).
Severity is CONDITIONAL on the caller passing safeattrsonly=False. With the class default (True), attribute allow-listing strips xlink:href before scheme scrubbing runs, and the bug does not fire — verified at HEAD: default-config Cleaner()(<svg><a xlink:href="javascript:…">x</a></svg>) → <svg><a>x</a></svg>.
Prior art / novelty
- CVE-2021-28957 (lxml 4.6.3) — same root cause, different attribute (formaction). Fix was a one-line extension of linkattrs. Direct precedent. - CVE-2022-34473 (Mozilla Sanitizer API) — xlink:href URL bypass primitive in a different sanitizer. - Bleach (Mozilla, Python) explicitly handles the xlink namespace; enshrined/svg-sanitize (PHP) ships cleanXlinkHrefs(); DOMPurify scrubs xlink:href via ALLOWEDURIREGEXP. - nh3 (the alternative recommended in lxmlhtmlclean's own README for security-sensitive use) is not vulnerable to this primitive — verified 2026-05-10 on nh3==0.3.5: with <svg>/<math>/<a> and xlink:href explicitly added to tags/attributes, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g. <svg><a rel="noopener noreferrer">x</a></svg>).
Coordination
Filing as a private GHSA at fedora-python/lxmlhtmlclean — lxmlhtmlclean is the canonical maintainer of the Cleaner code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (https://github.com/lxml/lxml/security/advisories/new returns 404 — private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream defs.linkattrs patch path. You're welcome to coordinate with them directly if you'd prefer the upstream fix over the in-package alternative above.
Happy to provide a draft patch or PR on either path. No bounty expected.
XMLRPC-C Library versions 1.07 through 1.67.01 are vulnerable to a reflected cross-site scripting (XSS) vulnerability in the error page component.