Synology warns of ransomware attacks exploiting a 2024 flaw in outdated NAS devices, urging users to update DSM immediately. A security fix released in 2024 is now at the centre of ransomware attacks against Synology NAS devices. The company has found attackers targeting systems that still run outdated versions of DiskStation Manager (DSM), putting files stored on these network storage devices at risk of encryption and extortion. Synology disclosed the attacks on October 29, 2026. Its investigation found that threat actors are taking advantage of a vulnerability that the vendor had already addressed in December 2024. “These attacks aim to encrypt data and extort ransom.” The warning highlights how devices left without security updates can remain exposed long after vendors have released a fix. The company hasn’t identified the exact vulnerability used in the attacks. Instead, it refers customers to Synology-SA-24:20, a security advisory published on November 5, 2024, which documents three flaws affecting DSM. The advisory was updated as fixes became available across different software branches, with the DSM 6.2 update released on December 5. The three vulnerabilities have different security implications. CVE-2024-10441 is the most severe, with a CVSS score of 9.8. It affects the system plugin daemon and could allow an unauthenticated remote attacker to execute arbitrary code on a vulnerable device. CVE-2024-50629 has a CVSS score of 5.3 and affects the DSM webapi component. It could allow remote attackers to read limited files. The third issue, CVE-2024-10445, is rated 4.3 and concerns improper certificate validation in the update functionality. It could allow an attacker in an adjacent network position to write limited files. Synology hasn’t confirmed which of these vulnerabilities attackers are exploiting. The three flaws should therefore be considered part of the security advisory, not three confirmed entry points in the current ransomware campaign. The vendor has released corrected builds for all the affected DSM branches. Users should check the full version number installed on their NAS and compare it with the minimum fixed releases listed in the advisory: DSM 7.2.2: 7.2.2-72806-1 or later. DSM 7.2.1: 7.2.1-69057-6 or later. DSM 7.2: 7.2-64570-4 or later. DSM 7.1: 7.1.1-42962-7 or later. DSM 6.2: 6.2.4-25556-8 or later. The impact of a ransomware infection on a NAS can extend well beyond the storage device itself. Businesses often use these systems to keep shared documents, operational files and backup copies in one place. If attackers encrypt that data, employees may lose access to essential information, while recovery can become much harder if the NAS also holds the backups needed to restore other systems. Updating DSM is therefore an immediate priority for administrators and home users alike. Synology is also advising customers to enable automatic updates so that future security fixes don’t depend entirely on someone checking for them manually. “Synology also recommends enabling automatic updates to keep DSM up to date at all times.” concludes the advisory. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, NAS)
Cybersecurity company Barracuda Networks warned customers to patch two vulnerabilities that can let attackers run commands with root privileges. The first is a critical flaw (CVE-2026-116606) stemming from an Email Security Gateway (ESG) authentication weakness that attackers can exploit to modify an appliance's global configuration, while the second (CVE-2026-111560) lets threat actors with admin permissions inject OS commands that run as root. However, Barracuda said successful exploitation also requires access to the administrative interfaces of targeted devices and advised customers to use appropriate network access controls and restrict access to trusted internal networks to limit exposure. "Successful exploitation requires an attacker to have access to the administrative interface of an affected product. If exploited in combination, these vulnerabilities could allow an attacker to bypass authorization controls and obtain root access to the device," the company explained.
A 3AM ransomware affiliate targeted a school estate in the UK and successfully encrypted around 37 of nearly 50 machines reached from an unmanaged host. Researchers at cybersecurity company Bitdefender believe the threat actor may have used AI-generated commands and an automated agentic loop to carry out the operation. The conclusion is based on a sequence of repeated commands that were slightly modified at each attempt and issued at roughly regular intervals of 40 to 100 seconds. "We were not able to access the machine the attacker worked from, so we cannot document anything about the language model itself: which model it was, whether it ran locally or remotely, or even whether a person was copying and pasting instructions and results between the implant and the model," Bitdefender explains.
Hackers who breached Harvard University's Alumni Affairs and Development systems in November 2025 stole data linked to more than 850,000 unique email addresses, according to breach notification service Have I Been Pwned. Harvard is a private Ivy League research university with over 20,000 faculty and staff, over 24,500 undergraduate and graduate students, and more than 400,000 alumni worldwide. As the university discovered on November 18, 2025, the attackers gained access to the personal information of students, alumni, donors, staff, and faculty members, including email addresses, telephone numbers, home and business addresses, event attendance records, donation details, and "biographical information pertaining to University fundraising and alumni engagement activities." However, Klara Jelinkova, Harvard's Vice President and University Chief Information Officer (CIO), said the breached IT systems didn't store Social Security numbers, passwords, payment card information, or financial information.
In an industrial network, malicious activity can be hard to tell apart from normal data exchange between devices. Malicious actors routinely rely on legitimate tools and the Living-off-the-Land technique, so a single network connection may show no known signs of an attack: the device uses a familiar protocol and transmits ordinary data. An anomaly can hide in subtle details: the data source, the time of access, or the volume of transferred data may be atypical for a particular device. However, to detect this kind of anomaly, you need to understand the roles of the devices at both ends of the connection and know which network activity patterns are typical for them. But an organization’s asset inventory data is often incomplete, which makes it harder to catch unauthorized connections in time. Suppose monitoring detects a host that regularly exchanges data with programmable logic controllers (PLCs). Its IP address is known, but the inventory does not specify what role it plays: is it an engineering workstation, a process data server, or a piece of contractor’s equipment? The host may also have been on the industrial network for a long time, with its record going out of date after a network upgrade. In the joint OT asset inventory guidance released by CISA and its partners in 2025, inventorying devices and classifying them by role are treated as part of OT asset management. For organizations, this is one of the most important areas: according to the SANS 2025 ICS security survey, 50% of respondents had deployed or significantly expanded ICS inventory and visibility tools over the previous 12 months, and 54% named them as investment priorities for the next 12–24 months. Device inventory in Kaspersky Industrial CyberSecurity for Networks In Kaspersky Industrial CyberSecurity for Networks, the Asset Discovery technology is the foundation of asset visibility. Passive network traffic analysis detects devices and their interactions, while recognition rules help determine the device category and extract available information about it, such as the vendor, model, or software version. Exactly which attributes the system can obtain depends on the protocol and the traffic it observes. We covered this in more detail at the Kaspersky Industrial Cybersecurity Conference. Hardware and software information in the device card The product also supports active polling modules (APMs): where polling is allowed, they can request additional configuration and firmware version details from devices. This kind of inventory is far more detailed than a list of IP addresses. Installed modules and their placement in a PLC rack However, even accurate hardware information doesn’t always explain what function a host performs in a specific industrial facility. Gaps appear for various reasons. Some devices send identifying information only at startup or during configuration, while others rarely communicate. Proprietary protocols can’t always be parsed, and encryption may leave only connection metadata for analysis. If the monitoring system doesn’t receive traffic from every segment of the industrial network, some network activity goes unobserved. Active polling doesn’t suit every device or every operating condition. Devices of unknown category When there isn’t enough direct information about a device, its category can be refined by looking at the patterns of its recurring network interactions. Analyzing these interactions is the job of Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0. This machine-learning-based event processor can both refine device categories and detect anomalies in their network behavior. What data does MLEP analyze? To compare device behavior, you don’t need to store every packet as a separate observation (a data object) in the ML model. MLEP represents network sessions as a sequence of short 15-second fragments. For each fragment, MLEP stores information about the endpoints (IP, MAC, and port), the direction of data exchange, the protocol, and the number and size of the packets transmitted. Together these make up an event, which then gets a timestamp. Traffic thus becomes a sequence of events showing which hosts a device communicated with, when, and how communication intensity changed. Aggregating data into events also sets the method’s limits. An aggregated fragment can’t be used to reconstruct the exact order of individual packets or the content of commands. MLEP can draw conclusions about a new protocol only if another KICS technology has managed to recognize it. That said, comparing stable network connections and changes in exchange volume doesn’t require a detailed record of every packet. These observations form the basis of the device’s behavioral history. From observations to MLEP results Each object has its own behavioral history, and one object’s history can’t be applied to another. But the principles of behavior analysis, along with some common rules, work across different objects. Let’s look at how this works in MLEP, which is built on a spiking neural semantic network (NSN). Event identification Neurosemantic networks structure information as a multilayer ordered graph, where the data in each consecutive layer builds on the data in the previous one. The nodes of this graph — that is, the units of information in each layer — act as neurons.The NSN creates dedicated channels to handle different event parameters (port, IP, and so on). Unique parameter values for each channel are stored as neurons in layer 0. The event itself, which consists of a set of parameter values, is stored as a neuron in layer 1 of the network. If an event occurs for the first time, neurogenesis creates a new neuron with input connections to the corresponding parameter neurons. This lets the network learn and operate on the event stream at the same time. If the event has occurred before, the network activates the same neuron that was created when the event first appeared. This way, the network identifies each event precisely. Each neuron that corresponds to an event also collects basic statistics: when it was last activated and how many times it has been activated. Event history In NSN-based event processing, layer 2 and above store sequences of events over time: recurring patterns and the full history. However, categorization and statistical anomaly detection don’t require storing the full packet sequence or a detailed timeline of every network event. As we noted earlier, events are themselves aggregates, which means the order of network packets has already been averaged out. So MLEP keeps history only temporarily, within each episode (30,000 aggregated events by default), which saves computing resources. Statistics processing in MLEP MLEP processes statistics mainly through specialized listener neurons on layer −1 (minus one) of the network. Attention heads and monitors are built on these neurons. Key components of the NSN When an event arrives, the corresponding neuron is activated, and the network instantly knows whether that neuron is new or was created earlier. Each attention head subscribes to the events or event features it needs and takes in only the activations of the matching neurons. If an event occurs for the first time, all heads are notified and then decide whether to subscribe (grow a connection to the relevant neuron) and receive information about activations of such neurons from then on. It is called a spiking network because activation information is a spike, not a number. This spike tells the head that something it’s interested in has happened. An attention head is configured according to scenarios — the situations that MLEP should send alerts about. The core of a head’s configuration is a query, which filters incoming information and serves as the subscription criterion. Unlike regular database queries, this query runs on the stream, so it can react to an event instantly. Attention heads work very much like the semantics of ordinary human language. A query has a subject of attention (one or more grammatical subjects) and conditions (the other parts of the sentence). In the infrastructure of an industrial enterprise, the subjects are devices on the network, and the conditions are various aspects of network communication, such as ports, protocol, and average packet size. If a head has many subjects (for example, if it’s interested in every device on an industrial network), it fans out: it creates a child head for each individual value of the subject of attention, that is, each device. The child head then watches a specific device and reports to the parent head. Attention heads don’t accumulate or process statistics. They only filter event streams. When an attention head receives a relevant event, it activates and sends a spike to the monitor subscribed to that head. Monitors, in turn, have stacks for accumulating and processing events. They can also have their own queries and post-filter information from the head. For example, they can select only new events from those filtered by the head. There are several types of monitors: Stat monitors track changes in the average count of specific events (for example, device activity) over time intervals typical for those events, or in the average values of numeric event parameters (for example, changes in device traffic volume). Monitors work from the event alone: they fire when an event has occurred a certain number of times within a given interval, or has occurred for the first time. Similar-behavior monitors work with heads that can generalize events, that is, extract just a few parameters whose combination is shared (generalized) across many events. MLEP uses these monitor types to implement scenarios for categorizing devices and detecting their anomalous behavior: For categorization, MLEP uses attention heads and monitors that identify common behavior across different assets and group devices accordingly. MLEP then takes information from Asset Discovery about the known categories of some assets and extends those categories to other assets in the same group. Because a device can show different types of activity, it may land in several groups. MLEP then makes a weighted assessment across all relevant groups. Groups of devices with similar network behavior At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs. MLEP takes a similar approach to anomaly detection: an attention head and a monitor define an anomaly scenario, often loosely. When a monitor activates on such a scenario, MLEP generates an alert about unusual behavior. The current version of MLEP ships with preconfigured heads and monitors. The functional dynamic diagram below shows how events from devices on an industrial network are processed. Event processing flow MLEP in practice: how behavior helps complete the asset inventory At a facility with several similar production lines, device information may be more complete on some lines than on others. On one line, devices are identified as PLCs, while on another, after an upgrade, some hosts show up only as addresses: the available traffic didn’t provide enough information to determine their category. Still, these devices communicate with the same types of HMIs and process data collection servers. Their communication directions, frequency, and volumes may be similar. That’s where MLEP comes in. It takes the categories of already known assets and matches recurring features of their network behavior against those of uncategorized devices. When the observed interactions turn out to be similar, MLEP can add a category for that host to the inventory. Device category suggested by MLEP Once the category is refined, the industrial network map provides more context about the equipment on the network. When analyzing network activity, the analyst immediately sees the device’s suggested category and can skip looking up each IP address in the design diagrams. This approach is especially useful where equipment changes faster than the documentation is updated. The suggested category is also checked against existing device information and defined constraints. This helps filter out some contradictory options, but prediction quality still depends on how much of the traffic is visible, especially if the device communicates only rarely. Anomalous activity and streaming statistics Investigations of real-world attacks show that attackers actively use both standard tools and permitted protocols. You don’t always need to know an attacker’s specific technique in advance to spot potentially malicious activity. Signature-based detection helps find known signs of an attack, but it doesn’t assess how typical an observed interaction is for a particular device. MLEP compares current activity with the device’s usual network profile: which hosts it communicates with, which protocols it uses, when and how much data it transmits, its average packet size, and so on. The changes it detects help guide the direction of the investigation. Correlating these changes with other events and the operational context helps determine whether malicious actions could be behind them. When investigating an incident that has already been detected, anomalies help reconstruct the sequence of actions. The first version of MLEP comes with six preconfigured monitors, one for each type of deviation from the device’s usual network profile: Anomaly How it helps with event analysis New external host Flags a new external connection that wasn’t previously seen in the device’s observed behavior, even if the IP address isn’t listed among known IoCs. Helps check whether this connection appeared at the same time as other suspicious events. New combination of destination address and port Shows that the device has begun using a service it hasn’t used before. Once an incident has been detected, this helps trace new connections after the more critical events have been analyzed. Unusually large volume of data sent Highlights data transfers that are atypical for the device and helps correlate their timing and direction with other events. Atypical activity time Shows that the device was active at a time that’s unusual for it. In an already detected incident, this helps reconstruct the timeline of actions around the main alert. New protocol Helps spot a new method of communication, even when the device is communicating with familiar hosts. Activity with signs of scanning Shows that the device has started contacting an unusually large number of neighboring hosts. This signal helps reveal possible reconnaissance ahead of attempts to access equipment. During an investigation, anomalies help reconstruct the sequence of changes: when a specific host established new connections, switched protocols, increased its data transfer volume, or shifted its operating hours. Matching events by device and time shows an analyst how activity unfolded around an incident that has already been detected. This is especially useful when some of the attacker’s actions fell outside the monitored scope or didn’t trigger other KICS technologies. Correlating these changes with the device’s role, protocol analysis data, and events from other technologies gives the analyst a more complete timeline. Behavioral anomalies show exactly where to look for the missing links and which network interactions need attention. Atypical Activity Time anomaly card In the event list, anomalies detected by MLEP are marked with an AI label. Each event shows its name, source, destination, timestamp, and the ID of the triggered scenario. Conclusion In an industrial network, whether behavior is anomalous depends on the host where it occurs and that host’s place in the industrial process. The repetitive nature of many communications makes a change in normal data exchange easier to spot, while knowing a device’s function and criticality helps gauge the possible consequences. Taken together, these observations make network traffic more than a list of connections: it helps assess new events in the context of a specific facility, even without an attack scenario known in advance. Machine learning technologies are well suited to this kind of comprehensive analysis, as they can process and organize huge streams of heterogeneous data. Starting with version 5.0, Kaspersky Industrial CyberSecurity for Networks handles this function with MLEP, which works effectively alongside the product’s existing functionality.
Google dismantled a 1.3 million-device botnet allegedly built by Android TV box maker Videostrong to enable ad fraud and proxy abuse. Google and its partners dismantled a backdoor called XCPE that had enrolled more than 1.3 million set-top boxes in a botnet. The result of the investigation into the malware operation is the striking part: Videostrong Technology Co., an Android device maker, built and ran the botnet for money. Google says it is highly confident that Videostrong deliberately created, spread and operated the backdoor. The company reportedly sold access to criminal groups and installed their malware on infected devices. The malware was used for ad fraud, secretly added devices to residential proxy networks and installed other malicious software. Google says this was not the work of a rogue employee or a simple coding mistake. The backdoor was found in many device models and brands over several years. Its operation involved dedicated infrastructure and regularly changing configurations. “We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM).” Google states. “Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices. “ Google has now cut all ties with Videostrong. The company is banned from making devices with pre-installed Google apps. The ban also covers any future subsidiaries or business partners, and Videostrong can no longer supply software to other certified device makers. Videostrong got around Google’s compatibility and security tests with code obfuscation. The malicious code loaded after a device’s first boot, which the tests didn’t catch. Google has changed its review process and is improving how it checks firmware on certified Android TV devices. Google also took legal action against the domains and servers Videostrong used to control the botnet, and against the control domains of over a dozen malware families loaded through the backdoor. Those affiliates spread their modules through other channels too, so Google expects the takedown to cut access to at least 10 million more compromised devices. Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI worked on the operation. The malware has three stages. The primary backdoor, x.cpe (called com.oemservice in some builds), is preloaded in the firmware and runs with system privileges. If a user uninstalls it, it reinstalls itself from the /oem/ partition at the next reboot. It handles communication with the control server and passes work to a loader called com.abc.nexus, which carries its own anti-analysis tricks and sets up the money-making modules. These modules are supplied by other criminals working as affiliates. They can arrive as programs built into the backdoor, software packages added to its loader, or extra apps downloaded later. Many turn the device into a residential proxy, allowing other people to use the victim’s home internet connection to hide their online activity. Others commit ad fraud or install additional backdoors. In other words, a set-top box becomes a proxy server without its owner’s knowledge. The backdoor uses two steps to control infected devices. First, the box sends an HTTP request to download settings, location data and network information. It then maintains a live connection through MQTT, a lightweight messaging protocol, to receive commands from the operators. Google found that all analyzed samples used the same MQTT server to communicate with infected devices. “Additional monetization modules as well as various shell scripts and legitimate applications are hosted remotely and downloaded by infected devices upon command from the operator via the MQTT broker.” continues the report. “A significant majority of these files are hosted as Github releases on operator-owned Github pages. Other files are hosted on operator-controlled servers and file hosting sites.” Through this connection, attackers could secretly install apps, run commands and scripts, take screenshots, record keystrokes and map the victim’s network. They could also disable Google Play Protect’s app verification to install software without the user’s knowledge. Google observed operators taking screenshots, recording keystrokes, collecting account and device information, stealing app lists and system logs, and opening remote command-line sessions. However, most of their activity involved installing, removing and managing malware modules. The malicious files came from several sources. The attackers mainly used GitHub releases hosted on their own accounts, the Filemail file-sharing service and two servers under their control. Network traffic analysis also suggests that the operators managed the command infrastructure through remote interfaces and an EMQX web console, connecting from IP addresses outside the infected device network. Most infected devices are Android TV set-top boxes, but Google also found telehealth devices, karaoke machines and digital signage. One device can run several modules at once, up to three residential proxy kits. That shows Videostrong wants to squeeze every infected device as hard as it can. The proxy and bandwidth-sharing kits named in the report include Linkfog, AppSalt, GaGaNode, BWM, Traffmonetizer, EarnFM and NetNut. Some of those kits enroll devices without asking. AppSalt’s SDK, owned by Honeygain, calls an opt-in function without showing any consent screen, and it stops running if the app came from the official Google Play Store. Ad-fraud modules such as Fission and HiddenView fire off fake ad impressions in the background, and HiddenView also uses hidden browser windows to simulate clicks and scrolling. The configuration shows a well-run operation. MQTT messages carry resource limits for each module, download links per processor type, and priority weights. Devices are assigned to one of six timezone-based pools on ott.szbboys[.]com. Devices report their bandwidth use and alarms back, so the modules stay within set limits. Google says the underlying market is resilient. Backdoor operators, ad-fraud rings and residential proxy providers work as an interconnected supply chain, and when one part gets disrupted they quickly switch to new loaders or rival kits. Lasting change, it says, needs accountability across hardware makers, the residential proxy industry and the broader technology sector. Google wants retailers and distributors to require independent security audits from device manufacturers and to delist any implicated in supply-chain abuse. It says proxy providers’ claims of ethical sourcing need transparent, auditable proof of user consent, and that in its analysis these providers asked for consent only when platform policy forced them to. Silent opt-in remains the most common way devices become exit nodes. For consumers, Google advises caution with apps that pay you for “unused bandwidth” or “sharing your internet”, which are a main way illicit proxy networks grow. Stick to app stores you trust, review permissions for third-party VPNs and proxies, and keep Google Play Protect on. Buy connected devices like set-top boxes only from reputable manufacturers, and check the partner list on Google’s Android TV website. Google also urges mobile platforms, ISPs, online marketplaces and other tech platforms to keep sharing intelligence. “A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust. By turning everyday hardware into persistent beachheads for criminal affiliates, Videostrong prioritized illicit post-sale recurring revenue over the safety and privacy of its users.” concludes the report. “Downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
NIS2 Article 20 makes management bodies answerable for the access controls they approve, and boards are starting to ask for proof that those controls work. NIS2 board accountability gives directors a more direct role in cybersecurity. Under Article 20, the management bodies of essential and important entities must approve the cybersecurity risk-management measures required by the directive, oversee their implementation, and can be held liable for infringements, subject to national law. That obligation is live across most of the EU, with four member states going to the Court of Justice in July for failing to notify full transposition. Access control is one of the required measures. Directors are not expected to decide who gets administrator rights or review individual user accounts. They do, however, need to know that access is being controlled, that someone has responsibility for managing the risk, and that problems are being addressed. An estimated 160,000 entities fall within the scope of NIS2 across the EU. Approval is only part of the job Article 20 requires management bodies to both approve cybersecurity risk-management measures and oversee their implementation. It also requires the members of those bodies to undergo cybersecurity training, and to offer comparable training to employees on a regular basis. The measures themselves are set out in Article 21. They include access control policies and asset management, along with the use of multi-factor authentication or continuous authentication solutions where appropriate. Many organizations have traditionally left these decisions to security and IT teams. Under NIS2, the board still needs to know whether the measures it approved are being implemented. Day-to-day responsibility can remain with the CISO and IT teams. The difficulty comes when the person responsible for a risk does not control the budget, systems, or people needed to address it. Greece’s implementation goes further in defining who carries that responsibility. Its NIS2 law requires essential and important entities to appoint a suitably qualified member of their organization as an Information and Communication Systems Security Officer. The officer coordinates compliance, must have the resources needed to do the job, and operates independently of the company’s data protection officer. Access problems also need to reach the board in terms that it can act on. If an MFA rollout has failed or administrators have more access than they need, the board needs to understand the risk of leaving it unresolved. The CISO may be responsible for the risk without controlling the budget or teams needed to fix it. The board needs evidence Board reports often show what the access control policy requires, rather than whether it is being followed. For example, a company policy will likely require MFA and the removal of accounts when employees leave. However, the board also needs to know about the exceptions, including old accounts that remain active, excessive privileges, MFA exemptions that have never been reviewed, and suppliers whose access has outlasted their contracts. The board needs information about how the controls are working in practice. In a NIS2 access management report from European password and secrets manager Passwork, regulators from two national cybersecurity authorities and independent security leaders describe boards that have absorbed the liability change and now ask for proof that controls work, where they once accepted a summary of the policy. Organizations should be able to show who can access critical systems, why that access was granted, who approved it, how long it is valid, and when it was changed or revoked. The board needs to know whether that evidence exists and what it says about material access risk. Personal liability raises the stakes Implementation is still catching up in parts of Europe. In July 2026, the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the European Union for failing to notify full transposition of NIS2 into national law. The Commission also asked the Court to impose financial sanctions. For organizations in countries where NIS2 has been transposed, regulators have significant enforcement powers. For essential entities, member states must set a maximum fine of at least €10,000,000 or 2% of the global annual turnover, whichever is higher. Important entities are subject to a lower maximum threshold, of at least €7,000,000 or 1.4% of their global annual turnover, in a similar capacity. Article 32 also allows competent authorities, in specific circumstances, to seek the temporary prohibition of someone at CEO or legal representative level from exercising managerial functions in an essential entity. This can happen where enforcement action has failed to produce the required response. It is not an automatic consequence of a cyber incident. Article 20 separately requires member states to ensure that management bodies can be held liable for infringements of Article 21, subject to the applicable rules under national law. Approving the policy is not the end of the board’s involvement. It also needs information on whether the policy is being followed and what is happening with known problems. Verizon’s 2026 Data Breach Investigations Report found credential abuse somewhere in the chain of 39% of breaches, more than any other vector. Stolen credentials also circulate at scale, as the exposed database of 24 billion credential records reported in June showed. Directors should expect an answer on which accounts and credentials reach critical systems, who is responsible for them, and whether that access is being controlled. Give access risk an owner with authority CISOs briefing their boards should be able to say who owns access-control risk and whether that person has the authority to address it. The board also needs evidence of what is happening. When an access problem is identified, someone needs to be responsible for getting it fixed. That might mean removing unnecessary privileges or dealing with an MFA exception that has remained in place. If the fix depends on another team’s budget or resources, the board needs to know. Board reporting should show whether the controls it approved are working, flag significant exceptions that remain unresolved, and who is accountable for closing them. Author the author: Kirsten Doyle has spent 27 years writing about technology and has covered the industry through some of its most significant shifts. Her focus areas include cybersecurity, cloud, channel, enterprise IT, and data centre operations. She works across many formats: news, features, white papers, eBooks, and thought leadership. Kirsten has many years of experience in journalism and editing for both print and digital media, and has supported plenty of go-to-market and PR programmes with technically grounded writing that holds up to scrutiny. She is also a regular writer at Bora. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, NIS2)
Synology is urging customers to update the DiskStation Manager (DSM) software powering its Network Attached Storage (NAS) devices following ransomware attacks. The Taiwanese vendor said it observed threat actors exploiting a vulnerability patched in December 2024 to target devices running outdated versions of DSM. "These attacks aim to encrypt data and extort ransom," it said in a statement
Threat actors are attempting to exploit an unpatched maximum-severity security vulnerability in the CryptoPayment Gateway WordPress plugin, according to findings from Defused Cyber. The vulnerability in question is CVE-2026-81648, which carries a CVSS score of 10.0. Successful exploitation of the flaw could permit unauthenticated users to delete arbitrary files on the server and extract
Financial technology company Abrigo has restored its Sageworks risk management application, except for borrower-facing capabilities, following an outage triggered by "irregular activity" in its environment. On October 30, the company began emergency maintenance and took the Sageworks application offline to investigate suspicious activity detected earlier that day, with the outage continuing through the weekend. Abrigo provides cloud-based software and analytics solutions for community banks and credit unions across the United States. According to the company, it serves more than 2,400 entities. Its Sageworks product is a software platform that helps lenders process loan applications, analyze borrowers’ finances, assess creditworthiness, and monitor loan portfolios. Due to its nature, Sageworks handles sensitive information, including banking customer details.
Confirm this action.
Leaving now will discard your changes.