What landed in CVE-land this week

"New CVE" and "new problem" are not synonymous. Several identifiers below carry old years — 2013, 2021, 2022 — but are landing in production environments right now through backported kernels, long-tail SaaS installs, and vendor re-triage. Defensive posture is set by what is exploitable in your environment today, not the year on the identifier.

The headline: xmlsec, still ambient

CVE-2022-47966 (CVSS 9.8) is a pre-auth RCE affecting a broad slate of Zoho ManageEngine on-prem products. The root cause: Apache Santuario (xmlsec for Java) 1.4.1 enables XSLT transforms by default, so an attacker who delivers a crafted SAML response to the SSO endpoint executes arbitrary Java. It has been weaponized in the wild since early 2023, and internet-exposed instances still surface in every quarterly external sweep.

If ManageEngine is anywhere in your estate, the right question isn't "have we patched" — it's "have we assumed breach on hosts exposed before the patch." Query your EDR for the classic post-exploitation chain: java.exe spawning cmd.exe or powershell.exe with -enc, plus unknown outbound on 443:

index=edr sourcetype=process_start
  parent_process_name IN ("java.exe","tomcat9.exe","ServiceDesk*.exe")
  process_name IN ("cmd.exe","powershell.exe","certutil.exe","bitsadmin.exe")
| stats count values(command_line) as cmd by host, parent_process_name
| where count > 0

The vulnerable primitive here is a design feature of an old dependency. Any Java product still shipping xmlsec ≤ 1.4.1 for SAML handling is a candidate for the same class. Grep your SBOMs.

The kernel cluster

Four Linux kernel entries came through the queue. Two are local privilege escalation, one is remote information disclosure via side-channel, and one is a race with limited practical impact. They overlap in the population of affected hosts — treat them as a group.

CVE-2021-27365 (CVSS 7.8) and CVE-2021-27364 (CVSS 7.1) are the iSCSI transport bugs discovered by GRIMM. Both live in drivers/scsi/scsi_transport_iscsi.c and are reachable by an unprivileged local user through Netlink messages that autoload the scsi_transport_iscsi module. CVE-2021-27365 is a heap buffer read/write with no PAGE_SIZE ceiling — a clean LPE primitive on any distro that autoloads the module on demand, which is most of them.

The compensating control isn't "patch fast" — most fleets are already past the patched minor version. Prevent the module from autoloading on hosts that don't need iSCSI initiator functionality:

# /etc/modprobe.d/blacklist-iscsi.conf
install scsi_transport_iscsi /bin/true
install libiscsi           /bin/true
install iscsi_tcp          /bin/true

Then verify no in-tree consumer will pull them back in. This "module autoload as attack-surface amplifier" pattern also covers CVE-2017-2636 (n_hdlc), CVE-2021-3490 (bpf), and a long tail of other LPEs — the modprobe hardening pays across the whole class.

CVE-2021-23134 (CVSS 7.8) is a use-after-free in NFC sockets. Default configurations require CAP_NET_RAW, which limits blast radius — but on systems with user namespaces enabled (the default on modern Ubuntu and Fedora), an unprivileged user acquires CAP_NET_RAW inside their namespace and can still reach the vulnerable path. If you can't patch, disable unprivileged user namespaces:

sysctl -w kernel.unprivileged_userns_clone=0     # Debian/Ubuntu
sysctl -w user.max_user_namespaces=0             # RHEL family

The same setting closes a wider class of bugs including CVE-2022-0185 and CVE-2022-25636.

CVE-2021-23133 (CVSS 6.7) is a race in SCTP sockets. Triggering it requires winning a narrow window during sctp_destroy_sock, and public PoCs have been unstable. Elevate its priority only if SCTP is in active use — confirm with lsmod | grep sctp before ranking it.

CVE-2021-20322 (CVSS 7.4) warrants a closer look: it needs no code execution. ICMP fragmentation-needed and redirect handling leaks enough state to reconstruct UDP socket source-port randomization, degrading the entropy DNS relies on to resist off-path attacks. A cache-poisoning attempt drops from infeasible to one-in-thousands. If you operate recursive DNS on Linux, this matters more than the raw CVSS indicates. Mitigations: enforce DNSSEC validation for zones you care about, and place resolvers behind egress firewalls that block ICMP redirects from unknown next-hops.

CVE-2022-3566 (CVSS 4.6) is a race in tcp_getsockopt/tcp_setsockopt. High trigger complexity, no reliable public primitive. Log it, patch on normal cadence, no escalation needed.

The oldie: Keystone request bomb

CVE-2013-0270 (CVSS 6.5) is an OpenStack Keystone DoS via oversized tenant names in token requests. Any well-maintained downstream fixed this over a decade ago. It surfaced in the feed this week from a re-scoring and vendor advisory refresh, not new exposure. No action required — unless you're running an abandoned fork on an air-gapped island, in which case add an ingress-level request-size limit in front of the Keystone API and move on.

What we're doing about it

  1. Pull the SBOM diff. Match every CVE against components we actually ship or operate. Anything outside the SBOM gets triaged to zero.
  2. Pull the exploitability signal. CISA KEV status, EPSS delta, public PoC availability. A CVSS 9.8 with no known exploit ranks below a CVSS 7.8 that's in KEV.
  3. Pull the compensating-control signal. For kernel LPEs, the question isn't "did we patch" — it's "is the vulnerable path reachable from an unprivileged process in production." Blacklisted modules, disabled user namespaces, and locked-down seccomp profiles change the answer.
  4. Verify with a check, not a claim. Every mitigation gets a probe. If you disabled scsi_transport_iscsi, a nightly test attempts to load it and alerts on success.

Step 4 separates a vulnerability-management program from a vulnerability-ticketing program. Vendor SLAs don't tell you whether a mitigation held under drift. A probe does.

Patch what you can. Ship compensating controls for the rest, and prove they work.

Verifiable security.