CISA Adds Three Known Exploited Vulnerabilities to Catalog

CISA’s addition of CVE-2023-49105, CVE-2026-53362 and CVE-2026-66384 to the Known Exploited Vulnerabilities Catalog deserves attention because these three vulnerabilities affect very different layers of enterprise infrastructure: file-sharing applications, the Linux kernel and software-development artifact repositories. What connects them is more important than their individual CVSS scores: CISA has evidence that attackers are exploiting them in real environments. That distinction should immediately change how organizations prioritize remediation. A vulnerability that is actively exploited and sits on an accessible attack path can represent substantially greater practical risk than a theoretically more severe vulnerability that attackers cannot reach.

The first vulnerability, CVE-2023-49105, affects ownCloud and is particularly serious because it can allow an attacker to access, modify or delete files without authentication under vulnerable configurations. The issue affects ownCloud versions beginning with 10.6.0 and prior to 10.13.1. Exploitation becomes possible when the attacker knows the username of the targeted ownCloud account and that user's account does not have a signing key configured. Because of improper authentication handling involving pre-signed URLs, the server can accept requests that should never have been considered authorized. The vulnerability carries a CVSS 3.1 score of 9.8, reflecting the potentially complete impact on confidentiality, integrity and availability of affected data.

What makes CVE-2023-49105 particularly dangerous is that the attacker does not necessarily need to compromise a password, steal a session token or defeat multi-factor authentication. Under the vulnerable condition, the security failure occurs before those conventional authentication defenses become relevant. This illustrates an important limitation of relying entirely on stronger login mechanisms as the solution to application security. MFA is extremely valuable when an attacker is attempting to impersonate a legitimate user, but it provides little protection when the application itself incorrectly decides that authentication is unnecessary.

The requirement that an attacker know the victim's username should also not provide much comfort. Usernames are frequently predictable, derived from corporate email addresses or obtainable through public information, previous breaches, directory enumeration, application interfaces or social networking platforms. In a targeted intrusion, discovering an employee's username is normally one of the easier reconnaissance tasks. A condition that effectively says “the attacker must know who they are attacking” is not a particularly formidable security boundary.

The consequences of unauthorized file access can extend considerably beyond the files initially exposed. ownCloud deployments are frequently used to store internal documents, project information, customer data, technical documentation, backups and other sensitive organizational content. If an attacker can read arbitrary files belonging to a victim, those documents may contain credentials, API tokens, infrastructure information or operational details that enable further compromise.

The ability to modify files is potentially even more serious. Integrity violations can be much harder to identify than straightforward data theft. An attacker could potentially alter documents, replace distributed files or manipulate information relied upon by other employees. Where ownCloud is integrated into collaborative workflows, malicious modifications could become a mechanism for delivering additional attack content or misleading users.

The ability to delete files introduces an availability dimension as well. Organizations therefore need to view CVE-2023-49105 as more than an information-disclosure problem. Depending on the affected account and stored information, exploitation can affect all three classical security properties: confidentiality through unauthorized reading, integrity through modification and availability through deletion.

Organizations that operated vulnerable ownCloud versions should therefore not stop after upgrading. Because CISA now considers the vulnerability actively exploited, previously exposed systems should be evaluated for evidence of unauthorized file access. Web server logs, ownCloud activity logs, unusual WebDAV requests and unexpected file modifications or deletions should be reviewed where historical telemetry remains available.

This is particularly important because patching answers only one question: “Can the vulnerability be exploited now?” It does not answer the equally important question: “Was the vulnerability exploited before we patched it?” Once a vulnerability enters the KEV Catalog, organizations should increasingly treat vulnerable exposed installations as potential incident-response cases rather than simply overdue maintenance items.

The second vulnerability, CVE-2026-53362, is considerably different because it exists inside the Linux kernel's IPv6 networking implementation. The issue occurs in the `__ip6_append_data()` processing path where incorrect accounting of fragment-gap data can result in data being written beyond the allocated socket buffer and into adjacent `skb_shared_info` memory. An unprivileged local user can trigger the condition using a UDPv6 socket in conjunction with specific message flags, making this fundamentally a local privilege-escalation and memory-corruption problem rather than an ordinary remotely exploitable network vulnerability.

The vulnerability affects Linux kernels beginning from the code change that introduced the faulty IPv6 behavior, with corrected versions subsequently released across supported stable kernel branches. Fixed releases include 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3, with later corrected kernel versions also incorporating the change. Distribution vendors may backport the fix, however, so administrators should use their Linux distribution's security advisory and package version rather than assuming that upstream kernel numbering directly reflects vulnerability status.

The phrase “local vulnerability” sometimes causes organizations to reduce priority automatically, but that would be a mistake with a KEV-listed kernel flaw. Local privilege escalation is extremely valuable after an attacker has obtained an initial foothold. An attacker might first compromise a web application, steal an SSH credential, exploit another service or gain access to a low-privileged container. CVE-2026-53362 can then potentially become the next stage of the attack by allowing that restricted foothold to attack the kernel itself.

This is why vulnerability-management programs should increasingly focus on attack chains instead of simply categorizing vulnerabilities as “remote” or “local.” A remote vulnerability providing low-privileged execution and a local kernel privilege-escalation vulnerability may individually appear less catastrophic than a single unauthenticated root-level RCE. When chained together, however, they can produce essentially the same result.

Kernel exploitation is particularly dangerous because the kernel represents one of the strongest privilege boundaries in the operating system. If an attacker successfully escalates into kernel-level or root-level control, application-level restrictions become considerably less meaningful. Credentials can potentially be extracted, security tooling interfered with, files manipulated and persistence mechanisms established outside the visibility of ordinary application monitoring.

CVE-2026-53362 is also significant for containerized infrastructure. Containers provide process and filesystem isolation, but multiple containers normally share the host kernel. A kernel vulnerability therefore exists beneath the container boundary. Whether a particular container can practically exploit a kernel flaw depends on its configuration, capabilities, namespace restrictions, seccomp policies and other controls, but security teams should avoid assuming that containerization automatically neutralizes host-kernel vulnerabilities.

This is one reason hardening containers remains important. Containers should run as non-root where possible, unnecessary Linux capabilities should be removed, seccomp and AppArmor or SELinux controls should be enforced, privileged containers should be heavily restricted and workloads with very different trust levels should not casually share the same host.

The vulnerability also reinforces the importance of keeping kernels current even when patching requires a reboot. Kernel updates are frequently delayed because application owners dislike maintenance downtime, and production teams understandably prefer not to reboot stable systems. Unfortunately, attackers do not suspend active exploitation while organizations negotiate a convenient maintenance window.

Where immediate kernel replacement is difficult, organizations should evaluate vendor-supported live-patching mechanisms where available, restrict local access, reduce exposure of vulnerable workloads and increase monitoring until permanent remediation can be applied. These should be treated as temporary risk reductions, not excuses to keep an actively exploited kernel indefinitely.

The third vulnerability, CVE-2026-66384, affects JFrog Artifactory and demonstrates why software-development infrastructure has become an increasingly valuable attacker target. The vulnerability is a path traversal weakness that can allow an authenticated user to write data outside the intended Docker cache path under specific remote-repository conditions. JFrog rates the flaw Medium with a CVSS 3.1 base score of 5.3, yet CISA has now added it to KEV based on active exploitation evidence. That difference between CVSS severity and exploitation priority is itself one of the most useful lessons from this announcement.

Affected self-hosted Artifactory versions include releases earlier than 7.146.35 and the 7.161 branch prior to 7.161.16. JFrog states that affected cloud environments have already been hardened, while self-hosted customers should upgrade to the appropriate fixed release.

At first glance, an authenticated path traversal vulnerability with a CVSS score around 5 may appear considerably less important than the ownCloud vulnerability. The fact that CISA has observed exploitation should force defenders to reconsider that assumption. CVSS attempts to describe technical severity under standardized conditions. It does not know whether attackers currently possess working exploitation techniques, whether the affected server stores sensitive software artifacts or whether compromising that server creates an attack path into the organization's entire development pipeline.

Artifactory frequently occupies a highly trusted position within software-development infrastructure. Developers, CI/CD systems and production deployment pipelines may retrieve packages, container images and dependencies from it automatically. That means artifact integrity is extremely important. If an attacker can influence content stored in an artifact repository, the consequences could potentially extend far beyond the Artifactory server itself.

A compromised ordinary web server affects the applications running on that server. Compromised software-supply infrastructure can potentially influence applications that have not even been deployed yet.

This is what makes artifact repositories attractive targets. Instead of compromising a hundred production servers individually, an attacker may attempt to compromise the location from which those servers receive trusted software. If malicious content enters a trusted build or deployment pipeline, legitimate automation can potentially distribute the attacker's payload further.

CVE-2026-66384 should not automatically be described as a complete software-supply-chain compromise, because the vendor describes a specific condition allowing authenticated data writes outside the intended Docker cache path. But its location within Artifactory means defenders should investigate the implications carefully rather than looking only at the vulnerability's numeric severity.

The authenticated requirement should similarly be placed in context. Modern attackers frequently obtain low-privileged credentials through phishing, leaked passwords, compromised developer accounts, exposed tokens and previous breaches. Once authenticated access exists, vulnerabilities that transform limited permissions into unintended filesystem writes can become valuable escalation mechanisms.

Organizations should therefore aggressively protect developer identities and machine credentials associated with Artifactory. Multi-factor authentication should be required for human administrative accounts where supported, API tokens should be narrowly scoped, CI/CD identities should receive only the repository permissions they genuinely need and credentials should be short-lived wherever practical.

The Artifactory vulnerability is particularly noteworthy when considered alongside the broader rise in attacks targeting development infrastructure. Source-code repositories, package registries, CI/CD servers and artifact repositories increasingly function as trust anchors for software organizations. Compromising them can provide access not merely to intellectual property but to credentials, signing infrastructure, deployment systems and downstream customer software.

Network architecture should reflect that importance. Artifactory administration should not generally be exposed openly to the internet. External access should be limited according to business requirements, management interfaces restricted to trusted administrative paths and repository permissions separated according to teams and workloads.

Self-hosted Artifactory organizations should upgrade to the fixed versions and then review whether their installation was reachable by accounts that could satisfy the exploitation prerequisites. Security teams should examine unusual repository operations, unexpected filesystem modifications, changes around Docker cache locations and activity from unfamiliar or low-privileged users.

File-integrity monitoring can provide valuable visibility because the essential security concern is unauthorized writing outside the intended location. Unexpected modifications within application or configuration directories should be investigated, particularly where timestamps correlate with unusual Artifactory requests.

Administrators should also review service-account privileges at the operating-system level. If the Artifactory process runs with unnecessarily broad permissions, a path traversal vulnerability can have much greater impact because the vulnerable process may be able to write into security-sensitive locations. Running services with tightly constrained filesystem permissions creates an additional boundary when application-level path validation fails.

This is a recurring principle across all three vulnerabilities: the severity of exploitation depends heavily on what privileges the vulnerable component already possesses. ownCloud should access only data required by the service. Application workloads should not possess unnecessary kernel capabilities. Artifactory should not run with unrestricted filesystem permissions. Least privilege cannot prevent every vulnerability, but it can prevent individual software defects from inheriting the maximum possible impact.

The three CVEs also provide an excellent illustration of why organizations should separate vulnerability management into initial-access and post-compromise categories. CVE-2023-49105 can potentially provide unauthenticated access directly to valuable data. CVE-2026-53362 can help an attacker escalate privileges after obtaining local code execution. CVE-2026-66384 can help an authenticated attacker cross filesystem boundaries inside critical development infrastructure.

An attacker does not need all three vulnerabilities in the same environment. The point is that adversaries think in stages. They search for whatever weakness provides initial access, then whatever weakness improves privileges, then whatever system provides access to valuable information or trusted infrastructure.

Security teams frequently organize vulnerabilities according to vendor because responsibility is divided internally: the Linux team patches the kernel, the application team handles ownCloud and the DevOps team manages Artifactory. Attackers enjoy this arrangement immensely because nobody on their side is required to respect the same organizational boundaries.

Attack-path analysis should therefore correlate vulnerabilities across systems. A low-severity vulnerability on a server directly reachable from a compromised developer account may be more important than a critical vulnerability isolated behind several controls. Context changes risk.

The KEV Catalog provides a valuable additional signal because CISA adds vulnerabilities only when there is evidence that exploitation has occurred and clear remediation guidance exists. A KEV entry should therefore move an affected asset substantially higher in the remediation queue compared with vulnerabilities that are severe only in theory.

This does not mean CVSS has become useless. CVSS describes technical characteristics of a vulnerability and remains valuable for standardization. KEV provides a different piece of information: attackers are actually using the vulnerability. Effective vulnerability management needs both types of context along with asset exposure, business criticality and available compensating controls.

CVE-2026-66384 demonstrates this exceptionally well. JFrog scores the vulnerability as Medium, yet CISA has observed sufficient exploitation evidence to place it in KEV. Organizations operating vulnerable Artifactory installations should therefore not allow a vulnerability-management system to automatically place it halfway down the remediation backlog merely because the numerical severity starts with a five.

Similarly, CVE-2023-49105 is not suddenly important because it was disclosed recently. The vulnerability dates back to 2023. Its addition to KEV in August 2026 demonstrates something defenders repeatedly encounter: old vulnerabilities do not expire simply because security teams have become bored of hearing about them.

A three-year-old vulnerability can suddenly become today's emergency if attackers identify enough exposed unpatched systems to make exploitation worthwhile.

This should encourage organizations to maintain much better visibility into unsupported and forgotten applications. Vulnerability scanners routinely identify thousands of findings, but old internal applications, departmental servers, inherited cloud instances and systems managed outside central IT often escape remediation processes entirely.

An actively exploited vulnerability discovered on one of these forgotten assets can rapidly become an attacker foothold. Asset inventory remains one of cybersecurity's least glamorous controls and one of its most important. An organization cannot patch an ownCloud server it does not know exists, and the attacker discovering it receives no consolation prize for respecting the asset register.

The CISA announcement should therefore trigger three parallel activities rather than a single patching campaign.

First, organizations should identify vulnerable assets and apply vendor remediation immediately according to exposure and business risk.

Second, they should investigate previously vulnerable systems for indications that exploitation may already have occurred.

Third, they should analyze what an attacker could reach if one of those systems were compromised.

The third step is frequently forgotten. A vulnerability assessment tells an organization where software is weak. Attack-path analysis tells the organization what that weakness can eventually become.

For ownCloud, defenders should determine what information affected users store, whether sensitive credentials or internal documentation may have been accessible and whether modified files could propagate elsewhere.

For CVE-2026-53362, defenders should determine which exposed or semi-trusted workloads could provide an attacker with the local access required to attack the kernel and what root-level compromise of those hosts would expose.

For Artifactory, defenders should determine which build systems, repositories, credentials and deployment pipelines trust the affected server.

These questions turn vulnerability management into actual risk management.

Another important change under CISA's current BOD 26-04 model is the increased emphasis on forensic triage for certain KEV assets. CISA is not merely asking federal organizations to install patches; the guidance also requires organizations, depending on exposure and impact characteristics, to consider whether the system may already have been compromised before remediation.

That is an important evolution in vulnerability-management thinking. Historically, patching often closed the ticket. With actively exploited vulnerabilities, patch deployment should increasingly trigger the question of historical compromise.

If an internet-facing server remained vulnerable for several weeks while active exploitation occurred, installing the patch today should not erase the need to examine yesterday.

Logs should therefore be preserved before major remediation wherever practical. Security teams should collect application logs, authentication data, operating-system telemetry, EDR information, firewall connections and relevant network-flow history before rebuilding systems or rotating away useful forensic evidence.

Where compromise is suspected, credential rotation should occur alongside technical remediation. An attacker who exploited a vulnerable application yesterday may not need the vulnerability tomorrow if they already stole a valid administrator token.

Network segmentation remains another important common defense against all three CVEs. An ownCloud server storing customer files should not possess unrestricted connectivity to management networks. A compromised Linux application server should not automatically communicate with domain controllers or administrative interfaces. An Artifactory server should interact only with documented development and deployment infrastructure.

Segmentation does not eliminate the vulnerability. It limits what the vulnerability can become.

Outbound restrictions similarly help contain successful exploitation. Production servers and artifact infrastructure frequently have predictable communication requirements. A compromised server that cannot freely connect to arbitrary internet destinations is considerably harder to convert into a persistent remote foothold.

Security teams should monitor unexpected outbound DNS queries, connections to newly observed addresses, large data transfers and downloads of unusual executables from affected systems. Post-exploitation activity often becomes more detectable than the original vulnerability exploit itself.

The Linux kernel vulnerability additionally demonstrates the importance of endpoint telemetry for privilege escalation. Sudden crashes, unexpected changes in effective privileges, suspicious namespace or socket activity and new root-level processes following activity by low-privileged accounts should receive investigation.

The ownCloud vulnerability requires a different detection approach. Security teams should focus on abnormal file access patterns, unusual WebDAV activity, access involving known usernames without expected authentication context and unexplained file changes or deletions.

Artifactory defenders should prioritize repository activity, authentication events and filesystem integrity. Unexpected operations from ordinary users, suspicious Docker repository activity and changes outside normal cache locations can provide useful investigation leads.

The broader lesson from the August 27 KEV update is that there is no single “critical vulnerability” profile. One of these vulnerabilities bypasses application authentication. Another corrupts kernel memory to facilitate privilege escalation. The third crosses filesystem boundaries inside critical software-development infrastructure.

Different technical mechanisms, different prerequisites and different consequences, yet all three are valuable enough that attackers are using them.

That is exactly why effective security programs need layers. Strong authentication helps against credential abuse but cannot repair an authentication-bypass vulnerability. Application hardening cannot compensate for an exploitable kernel. Kernel patching cannot protect a vulnerable artifact-management application. Network segmentation, least privilege, application security, endpoint monitoring, credential protection and patch management each address different sections of the attack chain.

Organizations should therefore avoid treating the KEV Catalog as merely another feed to ingest into an already overcrowded vulnerability dashboard. Its purpose is prioritization. Once exploitation is confirmed, defenders have evidence about attacker behavior that should influence remediation decisions immediately.

The most important practical takeaway from these three additions is straightforward: ownCloud installations vulnerable to CVE-2023-49105 should be upgraded and investigated for unauthorized historical file access; Linux systems potentially affected by CVE-2026-53362 should receive vendor kernel updates with particular attention to hosts accessible by untrusted or compromised users; and self-hosted JFrog Artifactory installations affected by CVE-2026-66384 should be moved to fixed releases while administrators review repository and filesystem activity for possible exploitation.

Perhaps the most useful lesson is the difference between vulnerability severity and vulnerability urgency. CVE-2023-49105 carries an obviously critical 9.8 rating. CVE-2026-66384 is vendor-rated Medium. Yet both now sit in CISA's Known Exploited Vulnerabilities Catalog.

Attackers have therefore supplied the piece of vulnerability intelligence that scoring systems cannot: evidence that the vulnerability is useful enough to exploit against real organizations.

A security team deciding what to patch first should pay very close attention when reality submits its own severity score.

CISA has added three new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2023-49105 ownCloud Improper Authentication Vulnerability CVE-2026-53362 Linux Kernel Unspecified Vulnerability CVE-2026-66384 JFrog Artifactory Improper Limitation of a Pathname to a Restricted Directory Vulnerability These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the spec

Source: CISA Adds Three Known Exploited Vulnerabilities to Catalog via CISA Advisories — published 27 Aug 2026.