[Security News] CISA Adds Two Exploited Flaws to KEV Catalog (6.25)

CISA’s June 25 updates put active exploitation, industrial control systems and browser-extension risk in the same security frame: patch known-exploited flaws…

CISA Adds Two Exploited Flaws to KEV Catalog (6.25)

Overview

CISA added CVE-2026-12569 and CVE-2026-20230 to its KEV catalog after finding evidence of active exploitation.
CISA’s June 25 industrial and medical advisories covered firmware, imaging, charging, camera and automation products with risks ranging from token theft to root-level access.
A Chrome extension item carried by feeds.feedburner.com said Adblock for YouTube had more than 10 million installs and dormant arbitrary JavaScript capability.
NIST, Microsoft and Google remain the reference points for CVE metadata, vendor update guidance and product security disclosures when teams triage June 25 vulnerability reports.

CISA Moves Two Actively Exploited Flaws Into KEV

CISA added two vulnerabilities to its Known Exploited Vulnerabilities catalog on June 25, citing evidence of active exploitation. The agency named CVE-2026-12569, an improper input validation issue in PTC Windchill and FlexPLM, and CVE-2026-20230, a Cisco vulnerability listed in the same alert.

The KEV catalog matters because it is not a general vulnerability list. CISA uses it for flaws with a CVE identifier, evidence of exploitation and mitigation guidance. That raises the operational priority for affected organizations, especially federal agencies and vendors that mirror KEV in patch-management workflows.

The practical message is direct: teams should treat these two CVEs as exploited, not theoretical. CISA’s supplied material did not include CVSS scores in the extracted evidence, so severity should be confirmed from vendor advisories or CVE records before final risk scoring. The exploitation status, however, is already the key signal for patch order.

▸ KEV additions deep dive

KEV entries are useful because they compress several triage questions into one signal. A vulnerability may have a high CVSS score and still remain hard to exploit in real environments. A KEV listing answers a different question: has someone already exploited it? On June 25, CISA answered yes for CVE-2026-12569 and CVE-2026-20230.

That distinction changes patch sequencing. Security teams often face hundreds of open CVEs across internet-facing services, internal applications, network devices and third-party platforms. CVSS helps estimate technical severity, but active exploitation helps decide what should move first. For these two entries, the exposure discussion should start with asset discovery: whether PTC Windchill, FlexPLM or the affected Cisco product exists in the environment, whether it is exposed to untrusted networks, and whether compensating controls can reduce risk before full remediation.

CVE-2026-12569 is described as improper input validation in PTC Windchill and FlexPLM. Input validation flaws can vary widely in impact, but the KEV listing means defenders should avoid treating it as a routine application bug. Windchill and FlexPLM are enterprise systems that may hold product, engineering or lifecycle data. That makes identity controls, logging and data-access review important alongside patching.

The Cisco entry, CVE-2026-20230, is less detailed in the supplied extract. That gap should not delay inventory work. Network and security appliances often sit in privileged positions, and a confirmed exploitation signal can matter even before every public detail is easy to parse. Teams should map Cisco assets, check vendor guidance and watch for any update that clarifies affected versions, fixed builds and workarounds.

There is also a policy dimension. KEV is widely used outside U.S. federal networks because it gives a conservative, evidence-based list of vulnerabilities that are already in attacker workflows. Organizations that cannot patch immediately should document why, apply mitigations, and increase monitoring around the affected products. The right response is measured but fast: verify exposure, apply vendor fixes where available, and keep exploit details out of internal broad distribution unless defenders need them.

CISA Advisories Point to Operational Technology Exposure

CISA also published a set of industrial control system and medical advisories on June 25. The affected products in the supplied data include Daktronics Controller Firmware, Delta Electronics DTM Soft, OHIF Viewers DICOM, H.VIEW HV-500S6 IP Camera, pydicom pynetdicom, Schneider Electric PowerLogic P7, Yokogawa FAST/TOOLS and CI Server, EVoke Systems Charging Station Management System, and Horner Automation Cscape.

The strongest warning in the extracted material concerns Daktronics Controller Firmware. CISA said successful exploitation could give an unauthenticated user complete root-level access and control of the system. The affected versions include VFC-DMP-5000 builds earlier than v8.117.x.x and earlier than v9.43.x.x, according to the advisory extract.

The same advisory set shows a broader pattern. Some issues involve arbitrary code execution, some involve file upload or file write behavior, and others involve unauthorized administrative control or service disruption. For defenders, the immediate question is not whether every advisory has the same severity. It is whether any affected product is reachable from an untrusted network or used in a safety-sensitive workflow.

▸ operational technology advisories deep dive

Industrial and medical advisories often look fragmented because they cover many vendors and product categories at once. The June 25 set is better read as a map of recurring failure modes. File handling, authentication boundaries, legacy protocol support and local execution paths appear across the supplied extracts. Those categories are familiar, but the operating context makes them more consequential.

Daktronics Controller Firmware is the clearest example. Root-level access from an unauthenticated position would move the issue beyond ordinary application compromise. In a controller environment, root control can mean durable access, configuration changes and loss of trust in the device state. The affected version ranges supplied by CISA give operators a concrete starting point: identify VFC-DMP-5000 deployments and compare firmware trains against the v8.117.x.x and v9.43.x.x thresholds.

Delta Electronics DTM Soft raises a different risk. CISA described successful exploitation as allowing arbitrary code execution. The extract also included a mitigation warning: users should verify the source of files before opening them and avoid launching the software with administrator privileges. That advice is basic but meaningful. If exploitation depends on opening a crafted file or running local tooling, removing administrative privileges can reduce blast radius.

The EVoke Systems Charging Station Management System advisory points to operational dependencies outside classic factory floors. CISA said exploitation could let attackers gain unauthorized administrative control over vulnerable charging stations or disrupt charging services through denial-of-service attacks. The extract adds that EVoke CSMS supports OCPP security profiles 0 through 3, but the effective connection security depends on the EVSE firmware. Legacy chargers supporting only Security Profile 0 or 1 may leave a weaker floor for authentication and transport protections.

Other advisories sit in adjacent risk categories. H.VIEW HV-500S6 IP Camera exploitation could allow arbitrary code execution and malicious file upload. Horner Automation Cscape could allow a local attacker to disclose information and execute arbitrary code. Yokogawa FAST/TOOLS and CI Server may return CI Server setting information. Schneider Electric PowerLogic P7 involves risks around privileged command execution or HMI operability if remediation is not applied.

The common operational lesson is asset context. A camera, controller, charging system or engineering workstation may not receive the same patch cadence as a cloud service. Some may be tied to uptime windows or vendor maintenance contracts. That makes compensating controls important: isolate affected systems, restrict administrative interfaces, limit file intake, remove unnecessary privileges and monitor for unusual configuration changes. Patching remains the preferred fix, but segmentation and least privilege can buy time when downtime windows are constrained.

Medical Imaging Flaws Raise Token and File-Write Risks

CISA’s medical advisories included OHIF Viewers DICOM and the pydicom pynetdicom Library. The OHIF advisory extract said successful exploitation in a custom integration version could let an attacker steal an authenticated clinician’s token through a crafted link. Affected OHIF DICOM Web Viewer Framework versions are v3.12.0 and earlier.

The OHIF issue is especially sensitive because it involves identity material, not only application behavior. CISA’s supplied facts state that a global authentication service automatically injects the authenticated user’s OIDC bearer token into resulting requests, sending it to an attacker-controlled server. CISA also listed fixes in OHIF/Viewers pull requests and recommended upgrading to v3.12.2 or later.

The pydicom pynetdicom advisory described another medical software risk. CISA said successful exploitation could allow an unauthenticated attacker to write to arbitrary file paths. The affected range in the supplied extract is pynetdicom versions from v1.0.0 through versions earlier than v3.0.4.

▸ medical imaging vulnerabilities deep dive

Medical imaging software has a distinct security profile because clinical workflows depend on fast access to images, studies and patient context. A vulnerability that exposes an authentication token can become more than an account-security issue. It can affect session integrity inside systems that clinicians use during care delivery.

The OHIF advisory shows how modern authentication can fail at integration boundaries. OpenID Connect bearer tokens are designed to let authenticated clients call protected services. If a global authentication service attaches that token to a request created from a crafted link, the token can move outside the trusted path. The supplied CISA extract says that is the relevant mechanism: the authenticated user’s token can be sent to an attacker-controlled server.

This is not the same as saying every OHIF deployment is equally exposed. CISA’s wording refers to a custom integration version. That detail matters. Organizations using OHIF should identify whether they run the affected DICOM Web Viewer Framework versions and whether custom integrations create external request paths. The recommended upgrade to v3.12.2 or later gives a clean remediation route where upgrade testing is possible.

The pydicom pynetdicom issue sits lower in the software stack. A library vulnerability can spread across many applications because the exposed product is not always visible in a user interface. The affected range, v1.0.0 through versions earlier than v3.0.4, is broad enough that medical software teams should check dependency manifests, containers and vendor-supplied packages. Arbitrary file write by an unauthenticated attacker can enable tampering, persistence or denial of service depending on file permissions and deployment layout.

For health care environments, remediation planning should include clinical operations staff as well as security teams. A viewer upgrade or library update may require validation against imaging workflows, authentication providers and DICOM routing. That does not reduce urgency. It changes the rollout plan. Teams should prioritize externally reachable integrations, systems handling clinician sessions, and deployments that accept network input without strong authentication.

The supplied data does not include CVSS scores for either medical advisory. That absence should be treated as a reporting limit, not as evidence of lower severity. The concrete facts are enough for action: affected versions are known, exploitation impact is described, and OHIF has a stated fixed version. In practice, that is enough to start remediation while formal scoring is checked through CISA, NIST or vendor channels.

Chrome Extension Report Adds Browser-Supply-Chain Concern

A June 25 item carried by feeds.feedburner.com reported that a popular Google Chrome ad blocker for YouTube had the ability to execute arbitrary JavaScript code. The extension was identified as Adblock for YouTube, with the ID cmedhionkhpnakcndndgjdbohmhepckk.

The report cited Island as the source of the analysis and said the extension had more than 10 million installs. It also said the extension carried a Featured badge on the Chrome Web Store. Those details matter because users often treat install count and store badging as trust signals.

The supplied evidence describes the script-injection capability as dormant. That leaves important questions unresolved, including whether the capability was abused, whether it was reachable through normal update channels, and what safeguards existed. Even so, browser extensions deserve close review because they run inside the user’s web session and can observe or alter page behavior.

▸ Chrome extension risk deep dive

Browser extensions occupy a privileged middle ground. They are not operating-system malware in the traditional sense, but they can interact with browsing sessions, page content and user workflows. A high-install extension with arbitrary JavaScript capability therefore creates a supply-chain question: what can the extension do after users have already granted trust?

The figure in the supplied report is large. More than 10 million installs means the potential exposure pool is not limited to a niche tool. The Featured badge adds a second trust layer. Many users do not read extension permissions closely, and organizations sometimes allow popular extensions unless a policy explicitly blocks them. That combination can let risky functionality persist even when no active abuse is publicly shown.

Dormant capability should be handled carefully in reporting. It does not prove exploitation. It does prove that the extension contained a mechanism that analysts considered able to execute arbitrary JavaScript. From a defender’s perspective, that is enough to justify review. Security teams can audit extension inventories, confirm whether the identified extension ID appears on managed browsers, and decide whether to block or remove it under enterprise policy.

The case also shows why extension governance needs more than reputation checks. Store presence, install count and badges are useful but incomplete signals. Organizations should focus on permissions, update history, developer identity, network behavior and whether the extension’s function requires broad page access. A single-purpose YouTube ad blocker should face scrutiny if its capabilities extend beyond that purpose.

For individual users, the least risky path is to remove unnecessary extensions and keep only those from vendors they deliberately trust. For organizations, the better path is central control: allowlist required extensions, block unapproved ones and monitor for extension IDs that appear outside policy. The supplied data does not include a CVE, a CVSS score or confirmed active exploitation, so this topic should not be conflated with CISA’s KEV entries. It belongs in the briefing because the scale and browser context make it operationally relevant.

Reference Sources Anchor Vulnerability Triage

NIST, Microsoft and Google appear in the June 25 source set as official reference points rather than incident-specific reports. NIST’s National Vulnerability Database provides CVE records and severity metadata. Microsoft’s Security Response Center maintains the Security Update Guide and vulnerability response information. Google’s Online Security Blog publishes product security and disclosure posts.

Those sources serve a different role from CISA alerts or single-product advisories. They help teams verify identifiers, affected products, severity data and vendor remediation language. That matters when daily collectors pull in partial extracts, truncated advisory text or feed summaries.

For this briefing, the distinction is important. CISA supplied the strongest dated evidence for active exploitation and product-specific advisories. NIST, Microsoft and Google provide the infrastructure that defenders use to confirm CVE metadata and vendor response details as the record matures.

▸ reference source workflow deep dive

Security teams rarely make patch decisions from one feed alone. A practical workflow starts with alerts, moves through vendor advisories, and then records decisions in internal risk systems. NIST, Microsoft and Google each support a different part of that process.

NIST’s National Vulnerability Database is the common reference for CVE records and severity metadata. It is useful when a CISA alert names a CVE but does not include every scoring detail in a feed extract. NVD records can also help standardize how a vulnerability is tracked across scanners, asset systems and ticketing tools. That standardization reduces duplicate work when one flaw appears under several product names or advisory labels.

Microsoft’s Security Update Guide matters most for Microsoft products and environments that depend on Microsoft’s official remediation wording. Even when a daily briefing is not centered on a Microsoft CVE, the guide remains part of the baseline for enterprise vulnerability management. It gives teams a vendor-maintained channel for patch availability, affected products and response changes.

Google’s Online Security Blog has a broader disclosure role. It can include product security work, research and vulnerability disclosure posts. For browser, Android, cloud or web security teams, Google’s official posts can clarify whether a reported issue affects a Google product, a research project or a wider ecosystem practice.

The editorial reason to separate these references from the main incident sections is accuracy. They are not substitutes for the dated CISA advisories in this source set. They are controls against over-reading partial data. If an extract lacks a CVSS score, affected version detail or fixed build number, reference sources help fill the record without relying on rumor or unsourced claims.

The same principle applies inside organizations. Security teams should store the alert source, the vendor source and the final remediation decision together. That makes later audits easier, especially when emergency patching creates exceptions. On June 25, the firmest action items come from CISA’s KEV and advisory material. The reference sources help validate and normalize those action items for ticketing, reporting and management review.

Morning Breaking Updates

microsoft.com: Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access - In this article Attack chain overview Mitigation and protection guidance References Learn more Microsoft Threat Intelligence has identified an active multi-stage intrusion campaign
microsoft.com: Microsoft a Leader in The Forrester Wave™ for Endpoint Management Platforms - The endpoint management category is being redefined in real time. Organizations no longer need tools that only inventory devices or enforce configuration policies; they need a plat

▸ More — additional context and sources

CISA Adds Two Known Exploited Vulnerabilities to Catalog

Reported by cisa.gov. Potential KEV additions must have a CVE ID, evidence of exploitation, and clear mitigation guidance.

Daktronics Controller Firmware

Reported by cisa.gov. There are exposed endpoints which allows authenticated users to upload files of any type without validation.

Chrome Ad Blocker with 10M+ Installs Found with Dormant Script Injection Capability

Reported by feeds.feedburner.com. An analysis of a popular Google Chrome ad block extension for YouTube has uncovered the ability to execute arbitrary JavaScript code.

ThreatsDay Bulletin: Smart TV Proxyware, 24-Year curl Bug, AI Crime Forums + 13 More Stories

Reported by feeds.feedburner.com. It’s dumb out there again. This week has the usual smell of prod on fire and nobody wanting to admit who left the door open — old creds still working, trusted apps doing sketchy crap, browser tricks…

At a glance

Fact	Publisher	Source
CISA added CVE-2026-12569 and CVE-2026-20230 to its KEV catalog.	cisa.gov	cisa.gov
Daktronics firmware flaws could give unauthenticated users root-level control.	cisa.gov	cisa.gov
OHIF Viewers DICOM versions through v3.12.0 are affected; v3.12.2 fixes the issue.	cisa.gov	cisa.gov
Adblock for YouTube had more than 10 million installs, according to Island.	feeds.feedburner.com	thehackernews.com
NIST maintains CVE records and severity metadata through the National Vulnerability Database.	NIST	nvd.nist.gov
Microsoft maintains official vulnerability response data in its Security Update Guide.	Microsoft	msrc.microsoft.com
Google publishes product security and vulnerability disclosure posts.	Google	security.googleblog.com

FAQ

Q1. What is the main security fact from June 25?

A. cisa.gov added two actively exploited vulnerabilities, CVE-2026-12569 and CVE-2026-20230, to the KEV catalog. That means exploitation evidence exists, so affected organizations should prioritize inventory, vendor guidance and remediation over routine backlog handling.

Q2. Which systems face the broadest operational impact?

A. cisa.gov listed multiple operational technology and medical products, including Daktronics Controller Firmware, OHIF Viewers DICOM, EVoke CSMS and H.VIEW cameras. The risks differ, but they include root-level access, token theft, file upload and service disruption.

Q3. What should teams do first if they use OHIF Viewers DICOM?

A. cisa.gov said OHIF DICOM Web Viewer Framework versions through v3.12.0 are affected and recommended upgrading to v3.12.2 or later. Teams should also review custom integrations that may send OIDC bearer tokens outside trusted destinations.

Q4. How is the Chrome extension report different from the CISA KEV items?

A. feeds.feedburner.com reported a dormant arbitrary JavaScript capability in an extension with more than 10 million installs. Unlike the KEV entries from cisa.gov, the supplied evidence does not state a CVE, CVSS score or confirmed active exploitation.

Q5. What should readers watch next?

A. Watch cisa.gov for revised advisories, NIST for CVE and severity metadata, and vendor channels such as Microsoft and Google for official response updates. The missing items to track are CVSS scores, affected-version clarifications and fixed-build guidance.

Sources

Last updated: 2026-06-26T00:33:20.520Z

Mini-Step

이 블로그 검색