CISA on June 25, 2026, published an industrial control systems advisory for Horner Automation Cscape versions before 10.2 SP3, warning that a local flaw in CSP file parsing could expose information and allow arbitrary code execution. The vulnerability is not remotely exploitable, and that matters. But dismissing it as “local only” would be the wrong lesson for factories, integrators, and Windows shops that treat engineering workstations as ordinary endpoints. In operational technology, the workstation is often the bridge between a malicious file and machinery that was never designed for hostile inputs.
The new advisory lands in familiar ICS territory: a high-severity bug, a vendor patch, and the reassurance that attackers cannot simply hit the vulnerable product over the internet. CVE-2026-12897 affects Horner Automation Cscape before 10.2 SP3 and sits in the way the software parses CSP project files. The failure mode is an out-of-bounds read, categorized under CWE-125, with a CVSS 3.1 score of 7.8 and a CVSS 4.0 score of 8.4.
That scoring can look odd at first glance. The CVSS 3.1 vector says local attack, low complexity, no privileges required, and user interaction required; the result is still high severity because the impact spans confidentiality, integrity, and availability. In plain English, an attacker needs to get a user or process to open a malicious file, but if that happens, the bug may disclose information or lead to code execution.
For Windows administrators, the shape of the risk should feel very familiar. This is the same basic pattern that has haunted Office documents, CAD files, compressed archives, and media parsers for decades: a trusted desktop application receives a crafted project file, mishandles memory, and the attacker’s code runs in the user’s context. The industrial twist is that the “document” may be a PLC or OCS project file, and the user opening it may be an engineer with privileged access to production systems.
That is why the “not exploitable remotely” line should calm internet-facing exposure panic without ending the conversation. The attacker’s route is not necessarily a socket on a PLC or a listening service in Cscape. It may be email, a file share, a vendor support package, a contractor handoff, a USB stick, or a project archive moved between laptops because that is how real plants often work.
This distinction matters because many OT security programs still divide the world into “the plant network” and “the corporate network,” then assume the firewall between them is the main event. A file parser bug in an engineering tool cuts across that model. The exploit may begin on a corporate laptop, a jump host, or an engineering workstation long before anyone tries to touch a controller.
The CSP file is the unit of trust here. Project files tend to accumulate authority over time because they represent known-good machine logic, hard-won commissioning work, and the tacit knowledge of whoever last made the line run correctly. Engineers open them because the job requires it. Attackers like that kind of file precisely because it is both operationally important and socially trusted.
A WindowsForum reader does not need to run a stamping press to recognize the pattern. Replace “CSP” with “DOCX,” “DWG,” or “PDF,” and the defensive posture becomes obvious: patch the parser, isolate the workstation, distrust unsolicited files, and assume that opening a project file is an execution-adjacent act rather than a harmless read-only operation. OT merely raises the stakes because the compromised machine may have pathways into equipment configuration and production availability.
For this Cscape flaw, user interaction is the obvious path: someone opens a crafted CSP file. That makes phishing and social engineering relevant even though the vulnerability is not remotely exploitable in the strict scoring sense. CISA’s own recommended practices emphasize avoiding unsolicited links and attachments for exactly this reason.
Industrial environments have a particular weakness here. Project files are routinely exchanged between OEMs, system integrators, plant engineers, maintenance contractors, and vendor support teams. The chain of custody may be more cultural than cryptographic: “This came from the integrator,” “this was on the old laptop,” or “this is the backup from the last shutdown.”
That workflow is defensible when everyone is trustworthy and every endpoint is clean. It is fragile when attackers understand that the engineering workstation is the soft underbelly of many control systems. A crafted project file does not need to defeat a perimeter firewall if it can ride along in a legitimate maintenance process.
The messy part is the validation cycle. Engineering tools in industrial settings are not always upgraded with the speed of consumer apps or even enterprise browsers. A new Cscape version may need to be tested against existing projects, controller firmware, third-party integrations, archived procedures, and the habits of technicians who have used the same toolchain for years.
That friction is real, but it is not a reason to sit still. The practical answer is staged urgency: install the fixed version first on non-production engineering workstations, validate project open/save behavior, confirm controller communication, then roll the update to systems that handle live or critical assets. Organizations that cannot patch immediately should restrict where CSP files can be opened and treat untrusted project files as hostile until proven otherwise.
There is also a documentation point that often gets missed. If your plant has a known-good engineering laptop image, golden VM, or disaster recovery kit, the patched Cscape installer belongs there too. Otherwise the organization may fix the daily workstation and later reintroduce the vulnerable version during a rebuild, outage, or emergency restore.
That does not excuse the bug. It does explain why ICS security cannot depend solely on vendor patch notes and perimeter diagrams. Engineering software has to be treated as part of the attack surface, especially when it parses complex project files from multiple parties.
The Windows world learned this lesson slowly with Office macros, ActiveX controls, browser plugins, media codecs, archive tools, and printer drivers. The answer was never one magic mitigation. It was a layered shift: automatic updates, protected view, attachment blocking, endpoint detection, application control, least privilege, and user training that eventually made “open this file” a much harder path for attackers.
OT has been slower to absorb that model because uptime, certification, and vendor support are legitimate constraints. But attackers do not care whether a parser runs in a corporate productivity suite or an engineering package. If it processes attacker-controlled bytes on a trusted Windows machine, it belongs in the vulnerability management program.
That machine should not be treated like a generic office PC. It should have tighter software inventory, stricter application control, better backup discipline, and clearer rules for file transfer. It should not be the same device used for web browsing, personal email, vendor portals, and casual document handling.
This is where Windows administrators can bring real value to OT teams. The core controls are familiar: keep the OS supported, remove local admin where possible, deploy endpoint protection that does not break the toolchain, log process execution, control USB storage, and isolate engineering systems from routine corporate traffic. The difference is that maintenance windows and operational risk need to be negotiated carefully with plant staff rather than imposed from a central IT calendar.
The best posture is not to pretend every engineering workstation can be locked down like a kiosk. It is to identify which workstations can touch controllers, which users can open and modify projects, and which file paths are trusted. Once that map exists, a vulnerability like CVE-2026-12897 becomes manageable instead of abstract.
That does not require turning every maintenance task into bureaucracy. It does require a few enforceable habits. Project files received by email should not be opened directly on production-connected workstations. Files from contractors should arrive through a controlled transfer path, preferably with hashes or signatures where the workflow supports it. Old project backups should be scanned and opened first in a sacrificial environment if their origin is unclear.
Virtual machines can help. A dedicated, patched analysis VM for opening untrusted or legacy automation project files gives teams a place to inspect content before it reaches the workstation with live controller access. Snapshots and network isolation are not a substitute for patching, but they are useful guardrails when file exchange is unavoidable.
This is also an argument for better project file inventory. If the only copy of a line’s logic lives on a laptop, the organization has an operational resilience problem as well as a cybersecurity problem. Version-controlled storage, access logging, and backup discipline make it easier to tell whether a suspicious file is truly part of the plant’s history or a new arrival wearing an old name.
For this vulnerability, network segmentation does not directly remove the file parser bug. A malicious CSP file can still be opened on a patched or unpatched workstation regardless of whether the PLC is internet-facing. But segmentation limits what a compromised workstation can reach next, and that is often the difference between an endpoint incident and an operational crisis.
The VPN warning is also worth taking seriously. Remote access is often where corporate IT and plant maintenance meet, and it is easy to treat VPN as a magic trust tunnel. A VPN only extends the security posture of the connecting device; if the contractor laptop or remote engineering workstation is compromised, the encrypted tunnel becomes a protected route for the attacker too.
The advice to perform impact analysis before deploying mitigations is not mere legal padding. Industrial systems can fail in expensive and dangerous ways when defenders move too quickly. Blocking a protocol, disabling a service, or updating a tool without testing can interrupt production. The mature response is not “never change”; it is “change with engineering discipline.”
Administrators should resist the temptation to overfit their response to the decimal. The qualitative facts are more important: exploitation is local, complexity is low, a crafted file is involved, and successful exploitation may expose information or enable arbitrary code execution. That combination justifies urgency even without known public exploitation.
The lack of known public exploitation is good news, but it is not a warranty. Once an advisory is public, defenders and attackers both know where to look. A patched version exists, the affected range is clear, and the vulnerability class points researchers toward file parsing behavior in CSP handling.
This is the uncomfortable rhythm of vulnerability disclosure. Public advisories enable defense, but they also compress the time available before proof-of-concept work appears or private exploitation becomes plausible. Organizations that already have Cscape in inventory should not wait for exploitation telemetry to become the forcing function.
Next comes patch deployment. Cscape 10.2 SP3 should be retrieved from the vendor and tested against representative projects before broad rollout. If the organization uses packaged software deployment, the installer should be wrapped, logged, and tracked like any other high-priority update.
Endpoint controls then matter more than usual. Application control can limit what executes after a successful exploit attempt. EDR can help detect abnormal child processes spawned by engineering software. Controlled Folder Access, least privilege, and network egress filtering can reduce the blast radius if an attacker gets code execution through a malicious file.
None of this should be sold to plant engineers as “IT locking down OT.” The better argument is operational continuity. A compromised engineering workstation can delay troubleshooting, corrupt trust in project files, and force emergency validation work at the worst possible time. Security controls that preserve the ability to safely maintain equipment are production controls by another name.
A high-severity local file parsing flaw exposes that ambiguity. The vulnerable software runs on Windows, but it serves industrial operations. The fix is a software update, but the validation burden belongs to the people who understand the machines. The attack path may start with email, but the consequence may live on the plant floor.
The organizations that handle this well will have a cross-functional patch process already in place. They will know which engineering applications are deployed, who approves upgrades, where test projects live, and how to roll back if an update breaks workflow. They will also know how to communicate the risk without sensationalizing it.
The organizations that struggle will be the ones that discover their inventory during the incident response process. They will find old laptops, undocumented installs, archived project files, and informal contractor practices only after the advisory forces the issue. That is not a Horner-specific problem. It is an OT governance problem wearing a CVE number.
But it is exactly the kind of advisory that should improve habits. File parser bugs in engineering tools are a durable class of risk. They exploit trust relationships, not just code defects. They turn routine maintenance artifacts into possible intrusion vehicles.
The concrete response is neither dramatic nor optional:
The Dangerous Part Is Not the Network Path
The new advisory lands in familiar ICS territory: a high-severity bug, a vendor patch, and the reassurance that attackers cannot simply hit the vulnerable product over the internet. CVE-2026-12897 affects Horner Automation Cscape before 10.2 SP3 and sits in the way the software parses CSP project files. The failure mode is an out-of-bounds read, categorized under CWE-125, with a CVSS 3.1 score of 7.8 and a CVSS 4.0 score of 8.4.That scoring can look odd at first glance. The CVSS 3.1 vector says local attack, low complexity, no privileges required, and user interaction required; the result is still high severity because the impact spans confidentiality, integrity, and availability. In plain English, an attacker needs to get a user or process to open a malicious file, but if that happens, the bug may disclose information or lead to code execution.
For Windows administrators, the shape of the risk should feel very familiar. This is the same basic pattern that has haunted Office documents, CAD files, compressed archives, and media parsers for decades: a trusted desktop application receives a crafted project file, mishandles memory, and the attacker’s code runs in the user’s context. The industrial twist is that the “document” may be a PLC or OCS project file, and the user opening it may be an engineer with privileged access to production systems.
That is why the “not exploitable remotely” line should calm internet-facing exposure panic without ending the conversation. The attacker’s route is not necessarily a socket on a PLC or a listening service in Cscape. It may be email, a file share, a vendor support package, a contractor handoff, a USB stick, or a project archive moved between laptops because that is how real plants often work.
Cscape Is a Windows Problem Before It Is an OT Problem
Cscape is not an obscure background component quietly humming inside a controller. It is engineering software: the Windows-side tool used to build, edit, and maintain automation projects for Horner systems. That makes the vulnerable surface the human workflow around automation, not merely the firmware boundary around the device.This distinction matters because many OT security programs still divide the world into “the plant network” and “the corporate network,” then assume the firewall between them is the main event. A file parser bug in an engineering tool cuts across that model. The exploit may begin on a corporate laptop, a jump host, or an engineering workstation long before anyone tries to touch a controller.
The CSP file is the unit of trust here. Project files tend to accumulate authority over time because they represent known-good machine logic, hard-won commissioning work, and the tacit knowledge of whoever last made the line run correctly. Engineers open them because the job requires it. Attackers like that kind of file precisely because it is both operationally important and socially trusted.
A WindowsForum reader does not need to run a stamping press to recognize the pattern. Replace “CSP” with “DOCX,” “DWG,” or “PDF,” and the defensive posture becomes obvious: patch the parser, isolate the workstation, distrust unsolicited files, and assume that opening a project file is an execution-adjacent act rather than a harmless read-only operation. OT merely raises the stakes because the compromised machine may have pathways into equipment configuration and production availability.
Local Exploitation Still Fits the Modern Intrusion Playbook
The word “local” can be misleading in vulnerability advisories. It does not mean an attacker must already be sitting at the keyboard. It usually means exploitation is not achieved by sending packets directly to a remotely exposed service; a local user action or local execution context is involved.For this Cscape flaw, user interaction is the obvious path: someone opens a crafted CSP file. That makes phishing and social engineering relevant even though the vulnerability is not remotely exploitable in the strict scoring sense. CISA’s own recommended practices emphasize avoiding unsolicited links and attachments for exactly this reason.
Industrial environments have a particular weakness here. Project files are routinely exchanged between OEMs, system integrators, plant engineers, maintenance contractors, and vendor support teams. The chain of custody may be more cultural than cryptographic: “This came from the integrator,” “this was on the old laptop,” or “this is the backup from the last shutdown.”
That workflow is defensible when everyone is trustworthy and every endpoint is clean. It is fragile when attackers understand that the engineering workstation is the soft underbelly of many control systems. A crafted project file does not need to defeat a perimeter firewall if it can ride along in a legitimate maintenance process.
The Patch Is Simple; The Upgrade Decision May Not Be
Horner Automation has released Cscape 10.2 SP3, and users of affected versions should move there. That is the clean part of the advisory. Anything before 10.2 SP3 is in the vulnerable range, and the vendor fix is the new service pack.The messy part is the validation cycle. Engineering tools in industrial settings are not always upgraded with the speed of consumer apps or even enterprise browsers. A new Cscape version may need to be tested against existing projects, controller firmware, third-party integrations, archived procedures, and the habits of technicians who have used the same toolchain for years.
That friction is real, but it is not a reason to sit still. The practical answer is staged urgency: install the fixed version first on non-production engineering workstations, validate project open/save behavior, confirm controller communication, then roll the update to systems that handle live or critical assets. Organizations that cannot patch immediately should restrict where CSP files can be opened and treat untrusted project files as hostile until proven otherwise.
There is also a documentation point that often gets missed. If your plant has a known-good engineering laptop image, golden VM, or disaster recovery kit, the patched Cscape installer belongs there too. Otherwise the organization may fix the daily workstation and later reintroduce the vulnerable version during a rebuild, outage, or emergency restore.
Another Cscape File Bug Tells a Larger Story
This advisory does not arrive in a vacuum. Horner Cscape has had previous high-severity file-handling issues, including earlier vulnerabilities where opening malicious project files could lead to code execution. The repetition is not unique to Horner; complex engineering applications often contain legacy parsers, binary file formats, and decades of compatibility commitments.That does not excuse the bug. It does explain why ICS security cannot depend solely on vendor patch notes and perimeter diagrams. Engineering software has to be treated as part of the attack surface, especially when it parses complex project files from multiple parties.
The Windows world learned this lesson slowly with Office macros, ActiveX controls, browser plugins, media codecs, archive tools, and printer drivers. The answer was never one magic mitigation. It was a layered shift: automatic updates, protected view, attachment blocking, endpoint detection, application control, least privilege, and user training that eventually made “open this file” a much harder path for attackers.
OT has been slower to absorb that model because uptime, certification, and vendor support are legitimate constraints. But attackers do not care whether a parser runs in a corporate productivity suite or an engineering package. If it processes attacker-controlled bytes on a trusted Windows machine, it belongs in the vulnerability management program.
The Engineering Workstation Deserves Tier-Zero Treatment
In many plants, the engineering workstation is more sensitive than its hardware suggests. It may look like an aging Windows box under a desk, but it can hold project files, credentials, controller connection profiles, serial adapters, VPN clients, and the institutional memory of how production actually runs.That machine should not be treated like a generic office PC. It should have tighter software inventory, stricter application control, better backup discipline, and clearer rules for file transfer. It should not be the same device used for web browsing, personal email, vendor portals, and casual document handling.
This is where Windows administrators can bring real value to OT teams. The core controls are familiar: keep the OS supported, remove local admin where possible, deploy endpoint protection that does not break the toolchain, log process execution, control USB storage, and isolate engineering systems from routine corporate traffic. The difference is that maintenance windows and operational risk need to be negotiated carefully with plant staff rather than imposed from a central IT calendar.
The best posture is not to pretend every engineering workstation can be locked down like a kiosk. It is to identify which workstations can touch controllers, which users can open and modify projects, and which file paths are trusted. Once that map exists, a vulnerability like CVE-2026-12897 becomes manageable instead of abstract.
File Provenance Is Now an Industrial Control
The most practical defensive change may be cultural: stop treating project files as inert artifacts. A CSP file should carry provenance expectations just as surely as a script, installer, or executable. If it came from outside the organization, it deserves quarantine, verification, and a controlled opening process.That does not require turning every maintenance task into bureaucracy. It does require a few enforceable habits. Project files received by email should not be opened directly on production-connected workstations. Files from contractors should arrive through a controlled transfer path, preferably with hashes or signatures where the workflow supports it. Old project backups should be scanned and opened first in a sacrificial environment if their origin is unclear.
Virtual machines can help. A dedicated, patched analysis VM for opening untrusted or legacy automation project files gives teams a place to inspect content before it reaches the workstation with live controller access. Snapshots and network isolation are not a substitute for patching, but they are useful guardrails when file exchange is unavoidable.
This is also an argument for better project file inventory. If the only copy of a line’s logic lives on a laptop, the organization has an operational resilience problem as well as a cybersecurity problem. Version-controlled storage, access logging, and backup discipline make it easier to tell whether a suspicious file is truly part of the plant’s history or a new arrival wearing an old name.
CISA’s Standard Advice Is Boring Because It Is Correct
CISA’s mitigation language will sound familiar to anyone who reads ICS advisories: minimize network exposure, keep control system devices off the open internet, put control networks behind firewalls, separate them from business networks, and use secure remote access such as updated VPNs when remote connectivity is necessary. It is boilerplate in the same way seatbelt advice is boilerplate. It keeps appearing because the failure patterns keep repeating.For this vulnerability, network segmentation does not directly remove the file parser bug. A malicious CSP file can still be opened on a patched or unpatched workstation regardless of whether the PLC is internet-facing. But segmentation limits what a compromised workstation can reach next, and that is often the difference between an endpoint incident and an operational crisis.
The VPN warning is also worth taking seriously. Remote access is often where corporate IT and plant maintenance meet, and it is easy to treat VPN as a magic trust tunnel. A VPN only extends the security posture of the connecting device; if the contractor laptop or remote engineering workstation is compromised, the encrypted tunnel becomes a protected route for the attacker too.
The advice to perform impact analysis before deploying mitigations is not mere legal padding. Industrial systems can fail in expensive and dangerous ways when defenders move too quickly. Blocking a protocol, disabling a service, or updating a tool without testing can interrupt production. The mature response is not “never change”; it is “change with engineering discipline.”
CVSS 3.1 and CVSS 4.0 Tell Two Versions of the Same Risk
The advisory includes both CVSS 3.1 and CVSS 4.0 scoring, and the difference is instructive. Under CVSS 3.1, the vulnerability scores 7.8 high with local attack vector and user interaction required. Under CVSS 4.0, it scores 8.4 high, reflecting a different scoring model that attempts to express vulnerable-system impact and subsequent-system impact more precisely.Administrators should resist the temptation to overfit their response to the decimal. The qualitative facts are more important: exploitation is local, complexity is low, a crafted file is involved, and successful exploitation may expose information or enable arbitrary code execution. That combination justifies urgency even without known public exploitation.
The lack of known public exploitation is good news, but it is not a warranty. Once an advisory is public, defenders and attackers both know where to look. A patched version exists, the affected range is clear, and the vulnerability class points researchers toward file parsing behavior in CSP handling.
This is the uncomfortable rhythm of vulnerability disclosure. Public advisories enable defense, but they also compress the time available before proof-of-concept work appears or private exploitation becomes plausible. Organizations that already have Cscape in inventory should not wait for exploitation telemetry to become the forcing function.
Windows Defenders Have a Playbook Ready
For Windows-heavy shops, the response should begin with asset discovery. Find machines with Cscape installed, determine the version, and separate ordinary engineering seats from workstations that can connect to controllers or production networks. If software inventory is weak, this advisory is a reminder that OT tooling must be visible in the same way browsers, VPN clients, and remote management agents are visible.Next comes patch deployment. Cscape 10.2 SP3 should be retrieved from the vendor and tested against representative projects before broad rollout. If the organization uses packaged software deployment, the installer should be wrapped, logged, and tracked like any other high-priority update.
Endpoint controls then matter more than usual. Application control can limit what executes after a successful exploit attempt. EDR can help detect abnormal child processes spawned by engineering software. Controlled Folder Access, least privilege, and network egress filtering can reduce the blast radius if an attacker gets code execution through a malicious file.
None of this should be sold to plant engineers as “IT locking down OT.” The better argument is operational continuity. A compromised engineering workstation can delay troubleshooting, corrupt trust in project files, and force emergency validation work at the worst possible time. Security controls that preserve the ability to safely maintain equipment are production controls by another name.
The Patch Window Is Also a Governance Test
Every ICS advisory tests not only technology but ownership. Who is responsible for Cscape in your environment: IT, OT, maintenance, the integrator, or a vendor support contract? If the answer is “everyone,” the practical answer may be “no one.”A high-severity local file parsing flaw exposes that ambiguity. The vulnerable software runs on Windows, but it serves industrial operations. The fix is a software update, but the validation burden belongs to the people who understand the machines. The attack path may start with email, but the consequence may live on the plant floor.
The organizations that handle this well will have a cross-functional patch process already in place. They will know which engineering applications are deployed, who approves upgrades, where test projects live, and how to roll back if an update breaks workflow. They will also know how to communicate the risk without sensationalizing it.
The organizations that struggle will be the ones that discover their inventory during the incident response process. They will find old laptops, undocumented installs, archived project files, and informal contractor practices only after the advisory forces the issue. That is not a Horner-specific problem. It is an OT governance problem wearing a CVE number.
The Cscape Advisory Is Small Enough to Fix and Big Enough to Learn From
This is not the kind of advisory that should trigger panic across the internet. The vulnerability is local, not remotely exploitable, and CISA says it has no reports of known public exploitation specifically targeting it. There is a vendor fix, and the affected version boundary is clear.But it is exactly the kind of advisory that should improve habits. File parser bugs in engineering tools are a durable class of risk. They exploit trust relationships, not just code defects. They turn routine maintenance artifacts into possible intrusion vehicles.
The concrete response is neither dramatic nor optional:
- Organizations running Horner Automation Cscape before 10.2 SP3 should prioritize testing and deploying Cscape 10.2 SP3.
- Engineering workstations that open CSP files should be inventoried, patched, monitored, and separated from routine office computing wherever practical.
- CSP project files from email, contractors, old backups, or removable media should be treated as potentially executable risk until their origin is verified.
- Teams that cannot patch immediately should restrict who can open CSP files and should use isolated environments for untrusted project inspection.
- Remote access into engineering environments should be reviewed because VPN connectivity does not make a compromised endpoint trustworthy.
- The advisory should be used to clarify ownership between IT, OT, maintenance, and integrators before a future vulnerability arrives under worse conditions.
References
- Primary source: CISA
Published: 2026-06-25T12:00:00+00:00
Horner Automation Cscape | CISA
www.cisa.gov
- Related coverage: incibe.es
Requisitos de contraseñas poco estrictos en productos de Horner Automation | INCIBE-CERT | INCIBE
Horner Automation tiene una vulnerabilidad de severidad crítica que, en caso de ser explotada, podríawww.incibe.es
- Related coverage: cyber.gc.ca
[Control systems] CISA ICS security advisories (AV26-368) - Canadian Centre for Cyber Security
[Control systems] CISA ICS security advisories (AV26-368)www.cyber.gc.ca - Related coverage: identitygatekeepers.com
Horner Automation IAM Security Threats & Vulnerabilities | Identity Gatekeepers – IAM Gatekeepers
IAM threat intelligence for Horner Automation. 1 identity and access management threats tracked over the last 30 days including credential theft, authentication
identitygatekeepers.com
- Related coverage: otwarden.com
ICSA-26-106-02 — Horner Automation Cscape and XL4, XL7 PLC — OTWarden
ICSA-26-106-02: Horner Automation Cscape and XL4, XL7 PLC. Severity: CRITICAL, CVSS 9.1. Affects Horner Automation.otwarden.com
- Related coverage: radar.offseq.com
CVE-2026-6284: CWE-521 in Horner Automation Cscape - Live Threat Intelligence - Threat Radar | OffSeq.com
Detailed information about CVE-2026-6284: CWE-521 in Horner Automation Cscape affecting Horner Automation Cscape. Get real-time updates, technical details, andradar.offseq.com
- Related coverage: vulnios.com
🔴 Horner Automation Cscape and XL4, XL7 PLC | Vulnios Threat Alert · Vulnios
View CSAF Summary Successful exploitation of this vulnerability could allow an attacker to gain unauthorized access to systems and services. The following versivulnios.com - Related coverage: knutmichael.com
Horner Automation Cscape and XL4, XL7 PLC — Radar — Knut Michael Haugland
Horner Automation PLCs have weak password requirements allowing network-based brute force attacks. The vendor has released updates for Cscape software…knutmichael.com
- Related coverage: windowsforum.com
Horner PLC Flaw CVE-2026-6284: Brute-Force Password Risk (CVSS 9.1 Critical) | Windows Forum
Horner Automation’s latest CISA advisory is a reminder that industrial cybersecurity problems do not always arrive as glamorous zero-click exploits or...windowsforum.com - Related coverage: hornerautomation.com
