Google has expanded its Cloud Vulnerability Reward Program (VRP) with a new top-tier reward for high-impact architectural security flaws. Starting this month, researchers can earn $250,000 for Root-in-Cloud bugs, including tenant-isolation bypasses and complex cross-service logic flaws that let attackers gain full administrative control over arbitrary Google Cloud organizations. "To earn this premier reward, you must demonstrate full administrative control, the equivalent of 'roles/owner' or complete IAM control, over arbitrary Google Cloud organizations or projects with no prior access or special project setup," said Chris Betz, Google Cloud's Chief Information Security Officer (CISO). "Additionally, valid vulnerability reports demonstrating remote code execution (RCE) in underlying Google production infrastructure (Borg) or achieving root-in-prod will automatically be evaluated by the Google Cloud VRP panel for root-in-cloud eligibility."
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)
Apple warns German Bundestag lawmakers of mercenary spyware attacks; BSI urges victims to assume compromise. The German government is warning politicians and public figures that they were targeted by government-backed spyware. The warning follows Apple’s notifications, which began reaching iPhones on October 29, according to the federal cybersecurity office, the BSI. The BSI says members of the Bundestag and other notable people got an Apple alert about an attack with so-called mercenary spyware. “The Federal Office for Information Security ( BSI ) has learned that several members of the German Bundestag and other public figures have received a threat notification from Apple on their devices since October 29, 2026. In the notification, Apple states that it has detected an attack using so-called mercenary spyware . This is commercially developed, advanced spyware that has frequently been used in the past by state actors against specific, targeted individuals.” reads the notice issued by BSI. “The BSI (Federal Office for Information Security) is unaware whether these notifications indicate actual compromises or merely signal attempted attacks.y “ “Germany’s digital minister, Karsten Wildberger, has confirmed that members of the Bundestag and the federal government received warnings from Apple that their iPhones may have been targeted by spyware.” states the report. Digital minister Karsten Wildberger confirmed it on ARD’s Bericht aus Berlin on Sunday, saying there had been “a notification from Apple that certain devices may have been compromised” and that members of both the Bundestag and the federal government were among those warned. Digital minister said the BSI had reacted super quickly and written to everyone affected. Wildberger didn’t say how many politicians got the alerts or who they are. “According to Wildberger, the BSI advised those affected to assume – as a precaution – that their device may have been compromised, because the alerts do not show whether an attack succeeded.” states Euronews. The German government has not revealed who was targeted. Government spokesperson Stefan Kornelius told the Financial Times that officials are taking the incident and Apple’s warning very seriously. However, he did not say which government members received the alerts or whether Chancellor Friedrich Merz was among them. Apple has not commented on the reports, according to Euronews. The Apple warning does not provide all the answers. Apple does not identify the governments behind these attacks, nor does it confirm whether a device was actually infected. Germany’s cybersecurity agency, the BSI, also says it is unclear whether the alerts indicate successful infections or only attempted attacks. Apple says mercenary spyware is far more advanced than common cybercrime tools and that most users will never be targeted. This commercial surveillance software is often used on behalf of governments to spy on specific individuals. It can infect devices through so-called zero-click attacks, which do not require victims to open a message or click a link. In most cases, victims do not notice anything unusual. Once a phone is compromised, the BSI says, attackers can read messages, including in encrypted apps, and access calls, contacts, calendars and location. They can also turn on the camera and microphone. That’s the whole phone, not a corner of it. For recipients the BSI’s advice is concrete. Update the operating system immediately, unless you plan a forensic analysis, and consider turning on Lockdown Mode, which makes new attacks harder but doesn’t remove an existing infection. Lockdown Mode limits some features such as message attachments, link previews and FaceTime calls from unknown people, while calls and plain text messages keep working. If the risk looks high, the BSI suggests replacing the device. That means resetting every account used on it and, to make repeat attacks harder, changing the phone number. Then set a new device passcode, change the passwords of your Apple account and email, and make sure two-factor authentication is on. The BSI recommends turning on Signal’s registration lock and WhatsApp’s two-step verification, with a new PIN for each. It also advises removing any linked devices you don’t recognize. Anyone who received a warning can email the BSI Service Center at service-center@bsi.bund.de. This helps the agency work out how many people may be affected. The agency says a genuine Apple warning never asks you to click links, open files, install apps or profiles, or share passwords and codes. These warnings appear on the lock screen, in settings, by email and at the top of account.apple.com after you sign in. The warnings weren’t limited to Germany. Beirut-based filmmaker Radwan Mortada said on X that Apple had warned him about another attack against his device. He had already been targeted by spyware in 2021. أمس، تلقيتُ إشعاراً أمنياً من شركة Apple تحذّرني فيه من تعرّض هاتفي الآيفون لهجوم تجسّسي موجّه، باستخدام برمجيات متطوّرة من النوع الذي تطوّره شركات مثل NSO Group، المعروفة ببرنامج «بيغاسوس». ولعلّ أخطر ما ورد في التحذير تأكيد Apple أنّ هذا النوع من الهجمات يستهدف أشخاصاً محدّدين… pic.twitter.com/2jFq6F3cvD — رُضوان (@radwanmortada) October 30, 2026 According to his notice, Apple sent the latest warnings to users in 99 countries. Nobody has publicly identified the attackers or the government that may have ordered the attacks. The BSI warned German lawmakers that Apple threat notifications may indicate compromised devices and urged recipients to contact the agency and take protective measures. “Those affected who have received a corresponding warning message from Apple should therefore assume that their device may have been compromised.” BSI concludes. “In a letter dated October 30, 2026, the German Federal Office for Information Security (BSI) alerted members of the German Bundestag to the threat and informed them of necessary measures. Affected individuals were urged to contact the BSI directly .” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Bundestag)
BTCPay Server, a self-hosted, open-source cryptocurrency payment processor, has urged users to install the latest version of its software in response to reports of Bitcoin and Litecoin being stolen from hot wallets on instances running older versions. "Our investigation found that these attacks targeted servers running BTCPay Server 2.4.1 (released on 23 July 2026) or earlier," BTCPay Server
Attackers remotely changed the settings on refrigeration controls at supermarkets in Belgium, Sweden, Estonia and other European countries overnight into Monday, November 2, warming fridges and freezers. No chain reported more than several dozen affected stores, and some had to throw away chilled and frozen food or take it off the shelf. Danfoss, a Danish maker of refrigeration controls,&nbsp
A maximum-severity security flaw impacting Siemens SIMATIC IoT2050 Advanced devices has come under active exploitation, VulnCheck has revealed. The vulnerability, tracked as CVE-2026-58115 (CVSS score: 10.0), is a case of missing authentication for a critical function that could be exploited by an unauthenticated remote attacker to run arbitrary code. "SIMATIC IoT2050 Advanced devices running
Unit 42 details recent threat intelligence, highlighting cyberespionage, financial extortion, and the rapid adoption of AI across offensive workflows. The post Unit 42 Threat Intelligence Highlights - Nov. 2, 2026 appeared first on Unit 42.
Confirm this action.
Leaving now will discard your changes.