3 new KEV entries: JFrog Artifactory, a Linux kernel IPv6 flaw, and an ownCloud auth bypass

On 2026-08-27, CISA added three vulnerabilities to the Known Exploited Vulnerabilities (KEV) catalog. The catalog is not a theoretical risk list. Inclusion means CISA has reliable evidence of exploitation in the wild; for federal civilian agencies it triggers a Binding Operational Directive 22-01 remediation clock. Private sector defenders should treat KEV entries with the same urgency: the same exploits reach commodity toolkits within days.

The three entries added on 2026-08-27 are:

The rest of this post covers each vulnerability: its mechanics, what CISA's exploitation signal likely rests on, how to confirm exposure, and what to ship inside the federal remediation window.

CVE-2026-66384: JFrog Artifactory path traversal in Docker cache

Artifactory is a build-time chokepoint. It fronts container registries, holds signed artifacts, and hands binaries to CI runners with high privilege. An authenticated write-outside-of-cache primitive on that surface is a supply-chain-adjacent bug, not a garden-variety directory traversal.

The KEV note classifies the flaw as CWE-22 (improper limitation of a pathname to a restricted directory) under specific remote-repository conditions. When Artifactory pulls a layer from an upstream Docker remote and stages it into local cache, a crafted layer or manifest can steer the write path outside the intended cache directory. Any write primitive on the Artifactory host is a candidate for planting a malicious JAR under a served repository path, dropping a webhook script, or overwriting a cron entry.

To triage exposure quickly:

# Enumerate Artifactory hosts with remote Docker repos configured
curl -sS -u "$AF_USER:$AF_TOKEN" \
  "https://artifactory.internal/artifactory/api/repositories?type=remote" \
  | jq -r '.[] | select(.packageType=="Docker") | [.key,.url] | @tsv'

# Then: check the running version
curl -sS -u "$AF_USER:$AF_TOKEN" \
  "https://artifactory.internal/artifactory/api/system/version" | jq .

Any instance that pulls from a public Docker upstream and is not on a JFrog-published fixed build should be treated as exposed. Compensating controls before patch: restrict which principals can create or edit remote Docker repositories, block outbound egress to arbitrary registries from the Artifactory host, and audit access.log for writes under the Docker cache root that resolve outside it.

CVE-2026-53362: Linux kernel IPv6 privilege escalation

The KEV note is deliberately terse: an unspecified privilege escalation in the IPv6 networking subsystem. Two things stand out. First, "unspecified" in KEV language usually reflects vendor-embargoed detail, not an unknown root cause. Second, IPv6 subsystem bugs frequently reduce to a race, a refcount error, or a slab corruption reachable from an unprivileged user via socket or netlink calls. That is the class of primitive container escape kits rely on, because it works from inside a namespaced workload with no capabilities.

The blast radius covers anything running an affected kernel: SUSE, Red Hat, and every downstream that tracks those trees. On a mixed fleet this typically includes Kubernetes worker nodes, developer laptops, and cloud VM images baked months ago and never re-rolled.

Two things to do this week:

# Inventory kernels across a fleet, keyed by host
for h in $(cat hosts.txt); do
  ssh "$h" 'printf "%s\t%s\n" "$(hostname)" "$(uname -r)"'
done | sort -k2

# On each host, confirm whether IPv6 is actually loaded and reachable
sysctl net.ipv6.conf.all.disable_ipv6
ss -H -6 -tuln | wc -l

If a host has no operational need for IPv6, disabling it on the box and at the network edge is a legitimate compensating control until the kernel update lands. For Kubernetes nodes, prioritize those hosting multi-tenant workloads, and enforce seccomp profiles that block obscure IPv6 socket options where possible.

CVE-2023-49105: ownCloud pre-auth file access

The ownCloud flaw is the oldest of the three by CVE year but the most immediately weaponizable. The condition set is narrow on paper and wide in practice: an attacker who knows a username and targets a user with no configured signing key can access, modify, or delete any file without credentials.

Usernames in most deployments are email prefixes, LDAP samAccountNames, or first.last patterns: guessable at scale. The "no signing key" precondition is the true filter, and in field deployments a nontrivial share of users never generate one.

Anyone still running ownCloud in 2026 should have this patched; it has been publicly known since late 2023. Its arrival on KEV signals that opportunistic scanning is converting on stragglers. If you cannot patch immediately, front the app with an authenticating reverse proxy or block the vulnerable endpoints at your WAF, and audit owncloud.log for anomalous file-access patterns tied to unauthenticated sessions.

The wider 2026-08 KEV wave

The three additions on 2026-08-27 landed on top of a heavy week. The 2026-08-26 batch added a Citrix NetScaler ADC/Gateway memory-safety flaw (CVE-2026-8452), an older Linux kernel out-of-bounds write (CVE-2022-0995), an AjaxPro deserialization RCE (CVE-2021-23758) against a likely end-of-life component, a Microsoft SQL Server RCE (CVE-2019-1068), and two legacy Red Hat local privilege escalations (CVE-2015-5287, CVE-2015-3246). Earlier in the week CISA also added a Gitea code injection via the diffpatch endpoint (CVE-2026-60004), an Oracle HTTP Server/WebLogic proxy plug-in access-control flaw (CVE-2026-21962), and a Zimbra SMTP command injection (CVE-2026-73570).

Two patterns stand out. First, developer-platform bugs (Artifactory, Gitea) are being catalogued alongside classic edge appliances: CISA now attests active exploitation on the build plane. Second, decade-old flaws in end-of-life or end-of-service software keep resurfacing. The remediation those entries demand is not a patch; it is retirement.

Meeting the deadline without theatre

BOD 22-01 gives federal civilian agencies a fixed window (typically two weeks for most KEV entries) to remediate or apply CISA-approved mitigations. The failure mode we see repeatedly is not "we did not know the CVE existed." It is "the asset inventory did not map the CVE to a host, or the host to an owner." Fix that instrumentation once, and every future KEV cycle collapses to a query.

Concretely, for this week: query your SBOM and configuration database for the vulnerable component and version range, tie each result to a service owner, and open a tracked ticket per host with the KEV due date as the SLA. Then verify: rerun the authenticated version check against every host in the ticket set after the change window and store the evidence. That evidence, not the patch itself, closes the loop.

Verifiable security.