CISA KEV: ownCloud, Linux, and Artifactory enter on the same day — with two different deadlines

The signal and the facts that change the decision

CISA added CVE-2023-49105 in ownCloud, CVE-2026-53362 in the Linux kernel, and CVE-2026-66384 in JFrog Artifactory to its exploited-vulnerabilities catalogue on 27 August. The feed assigns 30 August to the first two and 10 September to the third for US federal entities covered by the directive.

The KEV catalogue itself is the evidence of known exploitation; NVD describes the vulnerability, but a CVE entry alone does not prove active exploitation. The feed describes ownCloud as unauthenticated file access, modification, or deletion under specific conditions, and the Linux case as privilege escalation in the IPv6 subsystem.

The Artifactory entry describes an authenticated user writing outside the intended Docker cache path under specific remote-repository conditions. Treating three entries as one campaign or relying only on CVSS produces bad decisions. They are distinct products and vectors; an incomplete inventory can declare 'not applicable' while appliances, base images, runners, or managed services remain vulnerable.

Decision, limits, and stop condition

Portuguese organisations do not automatically inherit a US federal deadline, but confirmed exploitation changes technical priority. Triage should separate product presence, affected version, exposure, compensating controls, telemetry, and the ability to remediate or withdraw the service.

Treating three entries as one campaign or relying only on CVSS produces bad decisions. They are distinct products and vectors; an incomplete inventory can declare 'not applicable' while appliances, base images, runners, or managed services remain vulnerable.

Execution and proof of completion

Execution should start by querying cmdb, scanners, sboms, images, suppliers, and teams to prove presence or absence of each product and version. Then, isolating exposed assets, collecting indicators, preserving logs, and applying the official fix or a verifiable mitigation per vulnerability. Closure requires closing each asset with before/after version, time, owner, functional test, telemetry evidence, and an investigation decision.

The board closes only when all inventory sources converge, affected assets are fixed or isolated, and the team retains reviewable proof; an answer that omits suppliers and ephemeral environments remains open.

• querying CMDB, scanners, SBOMs, images, suppliers, and teams to prove presence or absence of each product and version.
• isolating exposed assets, collecting indicators, preserving logs, and applying the official fix or a verifiable mitigation per vulnerability.
• closing each asset with before/after version, time, owner, functional test, telemetry evidence, and an investigation decision.
• The board closes only when all inventory sources converge, affected assets are fixed or isolated, and the team retains reviewable proof; an answer that omits suppliers and ephemeral environments remains open.