42 publicly listable cloud buckets containing 18 billion files, including exposed credentials, database dumps and backups. The Ransomnews research team counted 484,142 publicly listable cloud storage buckets in October 2026, holding 18.05 billion files. They built the count from the search engines that index open cloud storage and published it as the Ransomnews Cloud Exposure Index, written by Mantas Sasnauskas. “No file was opened for this index. Every number below comes from bucket names, file extensions, file counts and last-modified timestamps. That is a deliberate limit. It keeps the research on the right side of the line, and it turns out to be enough to see where the sensitive material concentrates.” Ransomnews states. “We are calling it the Ransomnews Cloud Exposure Index, and we will rerun it quarterly so the numbers can be compared over time.” The researchers used bucket names, file types, file counts and last-modified dates to collect their data. They did not open any files, allowing them to identify where sensitive information might be stored without accessing the content. They plan to repeat the research every three months to track changes over time. Amazon S3 accounts for 72% of the exposed buckets, roughly in line with its share of the market. This does not mean S3 has weaker security than other providers. Azure Blob, however, appears 2.5 to 3.6 times more often than expected among buckets named for backups, data exports and payroll records. The researchers also found 321,058 files related to credentials and keys. Of the exposed .env files, 67% were last modified in 2026. Below is the split by provider, from a snapshot taken on October 7: ProviderOpen bucketsShareAmazon S3347,98471.9%Azure Blob68,53214.2%Google Cloud Storage53,13111.0%DigitalOcean Spaces11,0692.3%Alibaba OSS3,4260.7%Total484,142100% A lot of these buckets are public on purpose, holding website assets, CDN mirrors, open datasets and podcast archives. So the index isn’t 484,142 breaches. It’s the pool where breaches hide, and the rest of the report narrows it down to the stores that should never have been listable. “Azure, by a wide margin relative to its size. Azure Blob holds 14.2% of open buckets, but 37% of the 1,459 buckets with “backup” in the name, 42% of the 399 named for exports, and 51% of the 505 carrying HR or payroll terms.” continues the report. “Buckets named for logs, customers and databases sit at 35% to 36%, all around two and a half times Azure’s baseline.” The skew only shows up for operational data. Buckets named “dev” sit at Azure’s baseline of 15 percent, and “test” and “staging” fall below it, at 9 and 7 percent. The authors suspect Azure storage accounts more often hold line-of-business data such as backups, exports and HR systems that enterprises run on Microsoft, while S3 and Google Cloud carry more application assets. They call it a hypothesis the counts suggest and don’t prove, and it’s the first thing they want to test next time. By sector, retail and e-commerce names lead with 5,666 buckets, mostly storefront assets. The more worrying number is that names tied to regulated sectors (finance, healthcare, education, government, legal and HR) appear on 10,891 unique open buckets. Those are the places where a stray file most likely holds personal, health or financial records, and where regulators expect to hear about it. Sector (by bucket name)Open bucketsFiles in themRetail and e-commerce5,666269.9MFinance and insurance3,50858.0MHealthcare2,70947.9MMedia and entertainment2,696136.2MEducation2,39360.6MGaming2,29679.0MTravel and hospitality1,714118.7MReal estate1,13760.7MGovernment and public sector1,00036.2MLegal97811.3MCrypto63011.9MHR and payroll5058.4M Healthcare-related names appear in 2,709 buckets containing 47.9 million files. The researchers identified them using terms such as “hospital” (135 buckets), “patient” (135), “clinic” (277) and “dental” (331). HR and payroll is the smallest sector, with 505 buckets, 259 of which are hosted on Azure. These figures are based on names, not proof of ownership. The search matches parts of words, so “store” can refer to object storage as well as shops. A single bucket can also appear in two sectors. The exposed buckets also list about 4.7 million database and dump files, 15,130 mailbox archives, and tens of millions of spreadsheets and documents. Credential files are particularly concerning because they can turn a cloud misconfiguration into a real intrusion. File typeWhat it isFiles listed.pemCertificates and private keys113,285.envApp secrets and API keys80,495.p12Certificate bundles with keys33,268.keystoreJava and Android keystores27,229.ppkPuTTY SSH private keys24,302.pfxWindows certificate bundles23,352.ovpnOpenVPN client configs15,079.jksJava keystores2,421.htpasswdWeb server password files695.tfstateTerraform infrastructure state475.kdbxKeePass password vaults457 Each of these exists to grant access. A .env file is where developers keep database passwords and API keys. A .tfstate file is Terraform’s record of a whole cloud setup, often with secrets in plain text, and a .kdbx vault is encrypted but now open to anyone who wants to guess passwords offline. Some .pem files are public certificates and some files are test fixtures, so the counts are a ceiling on live secrets and not a measure of them. It’s still a big ceiling. Database files make up most of the sensitive material by volume: File typeWhat it usually holdsFiles listed.sqliteEmbedded app databases2,561,807.bakDatabase and server backups752,055.sqlDatabase dumps687,446.sqlite3Embedded app databases488,176.dumpDatabase dumps176,603.mdb / .accdbMicrosoft Access databases36,467.dmpMemory and crash dumps12,809.pst / .ost / .mboxMailbox archives15,130.emlSaved emails4,549,665.csvData exports and recordsat least 69,580,112.xlsx / .xlsSpreadsheets42,544,997.docxWord documents24,936,788.pdfDocuments, invoices, scansat least 106,191,393.logApplication and server logsat least 61,310,809 The exposed buckets contain thousands of virtual disk images, including VMware, Hyper-V and QEMU files. A single disk image can contain an entire server, including credentials. Some exposures involve active systems. Of 80,495 .env files, 67% were last modified in 2026. Certificates and SQLite databases include both recent and older files. Backups appear older, with 89% of the 752,055 .bak files last modified before 2025. Almost all PuTTY key files date from 2024. Recent leaks need urgent attention, while long-standing exposures point to poor security management. The problem is ongoing: at least 113.6 million files were added to publicly listable buckets in the seven days before September 9. Over the previous 30 days, these included more than 21,000 SQL dumps, nearly 21,000 backup files, 4,477 .pem files and 1,298 .env files. Public .env files can expose database passwords that ransomware affiliates and initial access brokers look for. Similar credentials appear in stolen-data logs, but in this case, attackers do not need to infect a device. They only need to search for exposed files. Cloud providers already offer settings to prevent public access. Organizations should enable S3 Block Public Access, disable anonymous access to Azure Blob storage, and enable public access prevention in Google Cloud. These controls should apply at account or organization level to prevent new storage buckets from becoming public. Organizations should also scan their storage for sensitive files such as .env, .sql, .bak, .pem, .ppk, .tfstate and .kdbx. Terraform state files and virtual disk images should be treated as secrets, stored privately, encrypted and monitored. Backups should never be publicly accessible, and recovery procedures must be tested. One exposed bucket may be a mistake, but many often indicate a wider process failure. Organizations need to fix the underlying security controls, not just individual buckets. The research has some limitations. The team queried search engines on October 25, while the bucket list was current to October 7 and the newest indexed file dated September 9. File-level data may therefore be about a month old. Counts are also capped at one million per query, so researchers split larger categories into date ranges and added the results. Some limits apply. The team queried the search engines on October 25. The bucket list was current to October 7 and the newest indexed file was dated September 9, so file-level figures lag by about a month. The index caps any single count at one million, so larger types were split into date windows and summed. A last-modified date shows when a file was written, not when it was exposed, and a listed file isn’t proof that its contents can be read. No bucket is named in the report. Exposures with a known owner in regulated sectors are going through responsible disclosure, with national CERTs copied where the owner is public sector or doesn’t respond. “Rotate any secret that has ever sat in a public bucket. Closing the bucket does not un-leak the key. Assume anything that was listable was copied.” conlcudes the report. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Cloud Buckets)
Cisco released security updates to patch a denial-of-service zero-day in Adaptive Security Appliance (ASA) and Threat Defense (FTD) software that attackers are exploiting to remotely crash vulnerable firewall devices. Tracked as CVE-2026-76418, this high-severity vulnerability affects devices running ASA and FTD software with configurations containing the 'webvpn' keyword and SSL VPN enabled on at least one interface. Successful exploitation allows unauthenticated, remote attackers to trigger a denial-of-service (DoS) condition, causing the device to reload unexpectedly. Cisco advised customers to patch vulnerable firewalls after its Product Security Incident Response Team (PSIRT) discovered evidence that the flaw was being exploited in the wild earlier this month. However, the company didn't provide indicators of compromise and hasn't shared additional information about the attacks, including which organizations are being targeted or who is exploiting the flaw.
Volt Typhoon used disposable relay chains to hide zero-day attacks on critical systems. Lumen linked Silent Train to at least four zero-days. Lumen’s Black Lotus Labs has spent three years tracking a covert network it calls Silent Train, which it ties to Volt Typhoon, the China-linked APT group. The cybersecurity firm says the network hid exploitation of software flaws the vendors didn’t know about yet. Black Lotus sent hundreds of victim notifications along the way, and the investigations that followed revealed the exploitation of at least four confirmed zero-days and one likely. “Volt Typhoon’s Silent Train is a covert network designed to gain and maintain access to the technologies businesses rely on to manage devices, networks and critical operations.” reads the report published by Lumen. “Black Lotus Labs® tracked how the group used rapidly changing chains of compromised infrastructure to conceal its activity while exploiting previously unknown vulnerabilities in centralized management platforms.” Silent Train first showed up in November 2023, shortly before the first takedown of the KV-botnet, Volt Typhoon’s earlier network of hijacked routers. Activity rose after the second disruption. The group dropped persistent infrastructure and moved to disposable chains of compromised devices that it could rebuild whenever it wanted. Each session began on a rented server outside the United States. It then passed through another server and compromised small-office routers, home devices and IoT equipment in other countries. Finally, the traffic passed through a compromised device in the U.S., close to the target. This helped the attackers make their activity look like normal local traffic and bypass location-based blocks and IP reputation filters. On average, the chains passed through about four devices before reaching a U.S. IP address. Some used as many as six. Lumen identified more than 27 types of devices used in the network, including TP-Link routers and Fortinet appliances. Some of these devices had no known vulnerabilities, suggesting that Volt Typhoon may have used previously unknown exploits to compromise them and create relay points. “We observed more than 27 device classes exploited and used in Silent Train operations, ranging from SOHO and IoT devices like TP-Link routers and Netgear Orbi devices to enterprise platforms like Fortinet appliances and CyberPanel servers.” the report continues. “Some relay device types lack known vulnerabilities, suggesting Volt Typhoon leveraged undisclosed zero-day exploits to set up a single relay in a four-to-six hop chain and indicating a willingness to commit significant resources to protecting future access capabilities.” The attackers exploited exposed web interfaces and installed only the tools needed to connect the devices through SSH. These included temporary SSH services, keys, configuration files and tools already available on the systems. At the end of each session, they removed all traces of their activity and dismantled the relay chain. Sessions lasted about four hours on average, although some lasted only minutes. The attackers could also build a new chain in less than two minutes, suggesting that they had partly automated the process. The group worked with strict discipline. New device types arrived about one per quarter, and about one per month during the 2023 and 2024 build-out, always tested outside the U.S. first. Roles never changed: Intelbras modems served only as overseas relays, Netgear Orbi devices only as the U.S. hops facing victims, and the server providers stayed separated by layer too. By early 2025, enterprise platforms like Fortinet, Cisco, PRTG, Mirth Connect and CyberPanel joined as final hops. They stayed up one to three months and supported several intrusions. The group also added reverse tunnels using the open-source proxies Chisel and FRP, and the old and new methods ran in parallel. Volt Typhoon used Silent Train only during key stages of its attacks, including exploiting vulnerabilities, stealing credentials and data, and maintaining access to compromised systems. Each session targeted between one and five victims, often just one organization. The activity was carried out by human operators, mainly from Monday to Friday, between 9 a.m. and 10 p.m. China Standard Time. The group also paused operations for several weeks around Chinese New Year. The group targeted tools used to manage endpoints and networks, as well as SD-WAN systems and other control platforms. These systems can manage hundreds or thousands of devices, allowing attackers to reach many systems without moving through the network in the usual way. This approach also helped them leave fewer traces. After the attacks, investigators found webshells running in memory, stolen credentials, misuse of built-in features such as remote file transfers, and deleted logs. The four confirmed zero-day campaigns hit Versa Director in 2024, N-able N-central through CVE-2025-8875 and CVE-2025-8876, Cisco Catalyst SD-WAN through CVE-2026-20127, and VeloCloud Orchestrator through CVE-2026-16812. The Cisco bug is a CVSS 10.0 flaw, and the group kept exploiting it well after Cisco disclosed it in February 2026. In the Versa case, the group used an in-memory JAR webshell to limit forensic evidence and reach downstream customers. The likely fifth is Quest KACE. The campaign hit more than 30 victims and faded after Quest’s October 2025 security updates. “The campaign affected more than 30 victims, followed vendor remediation timelines and declined after Quest’s October 2025 security updates.” the report states. “Despite limited forensic evidence, the available data supports a moderate-confidence assessment that Volt Typhoon exploited a zero-day vulnerability.” The actor stayed on the KACE server and used its admin features to take credentials. Victims include telecoms, government agencies, defense contractors, satellite and emergency communications, universities with ROTC programs, managed service and IT firms, and critical infrastructure such as water, energy, transportation, maritime, rail and aviation. What they share is access to bigger networks or customers. Hawaii, California and Texas were the top locations for several years. Lumen can’t say why, but the pattern fits pre-positioning for a crisis in the Indo-Pacific. “For enterprise leaders, the lesson is clear: systems with broad administrative reach can become high-value gateways to the entire organization and its customers. Reducing internet exposure, accelerating patching, strengthening access controls and preserving security telemetry are essential to detecting threats earlier and limiting their impact.” Lumen concludes. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, China)
Sony Network Communications has confirmed a data breach that compromised approximately 2.5 million records containing current and former customers’ personal information. A Sony Group Corporation subsidiary, the company provides telecommunications and technology services, acting as an internet service provider (ISP) in Japan. The breach occurred on October 19 and was detected four days later, when the company shut down the compromised servers and blocked external communication. In an announcement yesterday, the company said that its So-net member database, supporting its internet access service, was accessed by an unauthorized party. The investigation confirmed that a total of 2,585,481 customer records had been exposed, including the following types of information: No banking, payment card, or other account details were exposed.
PHP2Shell shows how quickly attackers can exploit critical vulnerabilities, often before organizations have time to patch. Token Security explains why limiting the access of service accounts, API keys, and AI agents is just as important as fixing vulnerabilities to reduce the damage from a breach.
Attackers have begun probing the Internet for systems unpatched against a recently disclosed critical Oracle E-Business Suite (EBS) vulnerability. Discovered in a core component of EBS's Application Object Library and tracked as CVE-2026-101767, this flaw lets unauthenticated threat actors with HTTP network access take over vulnerable systems in low-complexity attacks. Oracle released security updates to address the issue in its October 2026 Critical Security Patch Update on October 20 and urged customers to patch their systems immediately. "In some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches," it said. "Oracle therefore strongly recommends that customers remain on actively-supported versions and apply security patches without delay."
Modern phishing campaigns can compromise American businesses without relying on traditional credential theft. Attackers can abuse legitimate cloud services, authentication mechanisms, and trusted business workflows to gain access to corporate accounts while leaving fewer obvious signs behind. ANY.RUN's analysis of Skyw4lker, a device code phishing campaign primarily targeting U.S. organizations
Three Japan-focused cyberattacks show how AI helps hackers scale operations, while exploiting old systems and weak security remains key. In autumn 2026, Japanese companies and other organizations reported a series of data leaks involving their web systems. On October 9, Japan’s National Cybersecurity Office issued a warning to businesses, while the head of the ruling party’s cybersecurity team described cyberspace as being in a “state of emergency.” Researchers at Trend Micro studied three attack infrastructures to understand how hackers use AI. Their findings show three different approaches, ranging from limited AI assistance to systems that use AI agents to manage almost an entire attack. The researchers looked at files that attackers left on servers anyone could reach. These included attack scripts, lists of targets, logs, and records of commands. The files showed attacks on organizations in Japan and other countries. But the researchers could not see the victims’ own logs or network records. So they could not confirm every break-in, measure the full damage, or say who was behind it. Attackers also like to claim more success than they really had. The researchers only counted a result as real when the evidence backed it up. The three cases show that AI does not play the same role in every cyberattack. “The cases differ along two dimensions: how much of the attack AI handled and how confidently we can establish its involvement.” reads the report. “Case A used AI to drive the entire workflow, which we confirmed. Case B was human-led, with confirmed AI assistance in planning and tool development. Case C showed high-confidence indications of AI use in a limited role, such as tool development. All three were active in 2026, and much of the activity preceded the previously published ARTEX reports.” Case A: AI agents managed the attack workflow. The researchers confirmed the use of CyberStrikeAI, an open-source penetration-testing platform built around AI agents. It handled reconnaissance, vulnerability checks, exploitation, data theft and reporting as part of a repeatable process. The platform split tasks among multiple AI agents. One record mentioned a credential-search agent in a system that used 44 agents. The platform could also generate Japanese content, including forms and fake login pages. Researchers identified at least 19 target organizations, including at least 16 in Japan. The system worked on several targets at once and kept traffic to each organization relatively low. This made the activity harder to detect by checking the logs of a single victim. Despite this automation, the platform rarely gained deep access to target systems. In many cases, it had no active session or web shell and showed no evidence of stolen data. The clearest intrusion started through an administration page that was publicly accessible on an old web system. The attackers did not need to exploit a newly discovered vulnerability. Case B: A human attacker used AI to plan and build tools. In this case, the operator made the main decisions but used a large language model to speed up planning and tool development. The researchers found an attack plan written by an LLM that targeted services providing AI and GPU resources. The attacker presented requests as authorized security testing to get around the model’s safety limits. The researchers say this was a false claim, although they did not publish the exact method. The attacker also targeted AI infrastructure, including platforms for AI workflows, data processing and model inference. The researchers believe the goal may have been to gain access to computing resources that could be used to run AI models cheaply. Some intrusions had serious consequences. In one case, the attacker gained control across several systems, including an FTP service, a database, an administrator account, a web shell and SSH access. The attacker also restored backdoors after they had been removed. In another case, a geographic information system server was exposed with default credentials. This provided access to hundreds of thousands of land and business records, as well as Windows credentials and email data. The evidence confirmed that information was downloaded. However, the researchers found no evidence that AI carried out these attacks independently. It helped the operator plan and build tools, while the actual work relied mainly on scripts, existing software and human decisions. Case C: AI played a limited role. Here, the operator appears to have used AI mainly to develop tools and scripts. The researchers found no evidence that it was involved in planning or managing the wider operation. They rated AI involvement as highly likely, but not confirmed, because they found no direct evidence such as prompts or API keys. The operator ran at least six campaigns in 2026, targeting exposed VPN devices and Oracle WebLogic servers. The targets included devices from Cisco, Citrix, F5 and Yamaha. In attacks against Yamaha RTX1210 routers, the operator did not exploit a product vulnerability. Instead, the attacker used credentials found in configuration files. These credentials provided direct access to internal corporate networks. The researchers also found signs that AI may have helped write some commands and scripts. These included unusually structured comments and emoji used as status markers. Such clues can support an assessment, but they cannot prove AI use on their own. Japan was the main target in all three operations, but attackers also targeted other countries and regions. All three used Simplified Chinese, but this does not prove they came from the same group or location. “Simplified Chinese was the working language in all three infrastructures. Japan was the largest target country, although the operators also pursued nearby countries and regions. Entry points were exposed legacy systems or weaknesses left in default configurations.” concludes the report. “Target selection was opportunistic across industries: the operators sought systems that were easy to attack from outside and acted on what they found.” The main difference was how AI was used. In one case, AI agents managed much of the attack and worked on many targets at once. In another, AI helped a human plan attacks and build tools. In the third, AI was mainly used to develop tools. AI helped make attacks faster and easier to scale, but attackers still exploited familiar weaknesses, such as outdated web systems, exposed admin pages, default passwords and poorly secured network devices. Researchers also found that AI tools sometimes reported planned actions as successful, making it essential to verify their results. AI can also help defenders discover vulnerabilities. However, researchers found no evidence that these three operations used AI-discovered zero-day flaws. Their attacks relied on known vulnerabilities and poor security settings. The report identifies six main priorities for defenders: Review public-facing systems. Identify old web applications and update them or isolate them if they cannot be secured. Protect administration pages. Check that management interfaces are not exposed to the internet without a clear need and strong access controls. Secure VPNs and network devices. Review configurations, remove default credentials and check for reused passwords. Protect internal AI services. Include AI workflows, inference services and GPU systems in asset inventories, and check whether they are exposed. Improve monitoring. Look for low-volume attacks spread across many targets, which may be difficult to spot in the logs of a single organization. Prepare for AI misuse. Organizations that use LLMs for work should train staff to recognize requests that falsely claim to be authorized security testing. These security weaknesses existed long before AI became widely available. AI simply helps attackers find and exploit them faster and across more systems. The time between discovering a vulnerability and using it in an attack may also become shorter. Organizations should install security updates quickly and apply temporary protections when patches are not available. Researchers still don’t know who was behind the three operations, whether they were connected or how much damage they caused. Further reports may provide more answers. “The attackers’ identities, whether the three cases share an operator, the full scale of the damage, and the AI models used remain unresolved. Our observations come from attacker-side files and still require confirmation from the affected organizations.” concludes the report. “We are considering further technical reporting on individual cases: AI-driven activity in Case A, AI assistance in Case B, and limited AI assistance in Case C. We will also continue working with the relevant organizations.” The main lesson is clear: AI can make cyberattacks faster and larger, but the basic security priorities remain the same. Organizations must identify systems exposed to the internet, strengthen access controls and detect suspicious activity before attackers turn a simple weakness into a serious breach. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Italy)
Tailscale has released version 1.104.4 to fix flaws in its built-in SSH server that could let an attacker reach services and files on other servers that only the root user should be able to touch. The flaws are in how Tailscale SSH forwards network connections, a job the Tailscale background process carries out with root privileges. To use them, an attacker must
Italy ’s Parliament cyberattack highlights hybrid warfare risks and the need for transparency, stronger defenses and accountability. The cyberattack targeting email accounts at Italy’s Chamber of Deputies, including a parliamentary account assigned to Prime Minister Giorgia Meloni, raises questions that go well beyond the security of individual inboxes. At a time when European institutions face growing cyber pressure, the incident highlights how access to political communications can become part of a broader hybrid warfare strategy. The Chamber confirmed that its IT systems had been targeted and said it had activated security measures in cooperation with Italy’s National Cybersecurity Agency (ACN). According to reports, three parliamentary email accounts were affected, including those associated with Meloni, former Justice undersecretary Andrea Delmastro and lawmaker Paolo Formentini. Palazzo Chigi clarified that the account assigned to Meloni was not the one she uses for government communications. That distinction matters, but it does not settle the broader security questions raised by the incident. The public information available so far does not provide a complete technical account of what happened, what level of access the attackers may have obtained, or whether any information was taken. The Chamber described the incident as having no emergency implications, adding that attacks of this kind occur daily. It also confirmed that similar attempts and pressure on IT systems had intensified in recent days, affecting other Italian, European and international institutions. This combination of statements deserves closer scrutiny. Cyberattacks may be a daily occurrence, but their frequency does not make every incident routine or harmless. The significance of an attack depends on the target, the access obtained, the information exposed and the wider strategic context. An email account is more than a channel for exchanging messages. It can reveal professional relationships, contacts, ongoing discussions, schedules and the way an institution operates. Depending on the level of access obtained, an attacker may also find documents, personal information or details that could help target other officials. A compromised account can provide a starting point for further attacks. Messages sent from a legitimate address may appear trustworthy, making it easier to approach colleagues, political staff or external partners. Information gathered from correspondence can also support impersonation, targeted phishing or attempts to obtain access to other systems. Even an account that is not used for government business can therefore have intelligence value. The important question is not simply whether an account handles classified information, but what an attacker could learn from it and how that information might be used. The distinction between an attempted attack and a confirmed compromise is equally important. Public statements have not yet provided enough technical detail to establish the full extent of the incident. Investigators need to determine whether access was blocked, whether an account was accessed, whether messages were read and whether credentials or other information were exposed. These are different scenarios, with different implications for security. The incident should also be considered against the backdrop of growing cyber pressure on public institutions. On October 8, Italy’s Foreign Ministry was targeted by a distributed denial-of-service (DDoS) attack that media reports linked to pro-Russian actors. A DDoS attack and an intrusion targeting email accounts are technically different operations, and there is currently no public evidence linking the two incidents. Their broader significance, however, lies in the pressure they place on institutions and the range of objectives that cyber operations can serve. Hybrid warfare does not rely on a single method. It can combine cyber operations, intelligence gathering, propaganda, disinformation, economic pressure and other activities designed to exploit weaknesses or influence decision-making. These actions do not necessarily need to be coordinated in every case to contribute to a more hostile strategic environment. In this context, a cyber operation does not need to shut down a public service to have an impact. An attacker who gains access to political correspondence may seek information about relationships between officials, internal priorities or ongoing discussions. That information could potentially support intelligence operations, help prepare future intrusions or provide material for influence campaigns. Stolen communications can also be selectively leaked, manipulated or presented without context to damage reputations and undermine public trust. The value of such material may lie less in its immediate technical impact than in how it can be used later. These are possible scenarios, not established facts about the attack on the Chamber. The public perception of an incident can itself become part of the problem. A successful intrusion, if confirmed, can raise doubts about an institution’s ability to protect sensitive communications. A poorly handled response can deepen those doubts, particularly if officials appear more concerned with reassuring the public than explaining what happened. None of this proves that the attack was directed by a foreign government or formed part of a coordinated influence operation. Attribution requires technical evidence, intelligence and careful analysis. Treating hybrid warfare as a serious risk means investigating these possibilities without presenting them as conclusions before the evidence supports them. The Chamber’s statement that the incident was not an emergency because similar attacks occur daily is, at best, an inadequate explanation of the risk. It confuses the frequency of attacks with the seriousness of their potential consequences. Reassurance has a legitimate role in crisis communication. Institutions should prevent unnecessary alarm and explain when protective measures are working. But reassurance is not a substitute for transparency, especially when the technical investigation is still underway. The Chamber has acknowledged that cyber pressure has increased against other institutions in Italy and abroad. That admission makes it even more important to explain the nature of the threat and the measures being taken to address it. A responsible update should clarify what is known about the affected systems, which protective controls were activated, what investigators have established and which questions remain open. Sensitive technical details can be withheld when their disclosure could compromise an investigation or expose additional weaknesses. That does not justify treating the incident as unremarkable before its impact is understood. The response also needs to go beyond public statements. Authorities should review access controls, authentication mechanisms, account monitoring, email forwarding rules and the procedures used to detect suspicious activity. They should assess whether accounts that are no longer needed remain active and whether older accounts receive the same protection and monitoring as those used every day. The objective is not to assume that a dormant account caused the incident, but to ensure that every account represents only an acceptable level of risk. The attack should prompt a broader review of how parliamentary communications are protected and how cyber incidents are handled. New agencies, appointments and organizational structures can contribute to security, but they do not guarantee it. Their value depends on clear responsibilities, technical expertise, adequate resources, tested response procedures and measurable results. Cooperation between the Chamber and the ACN is important, but the public also needs a clear account of how the incident is being investigated and what corrective action follows. Where the investigation establishes weaknesses, those weaknesses must be addressed rather than obscured by general assurances. The challenge is particularly significant as Italy and other European countries prepare for future elections. Political institutions may face not only attempts to disrupt their services but also operations intended to collect information, exploit internal divisions or influence public debate. Cybersecurity is therefore part of democratic resilience, alongside the ability to identify manipulated information, communicate reliably and maintain public confidence. The first priority must be to establish what happened at the Chamber and avoid unsupported claims about the attackers’ identity or objectives. The next is to use the findings to strengthen the security of parliamentary communications and other institutional systems. An institution’s response should be judged not by its claims that an attack is under control, but by its ability to establish what happened, communicate the risks clearly and fix the weaknesses identified. As hybrid threats grow, downplaying an incident before its implications are fully understood sends the wrong message: protecting the institution’s public image appears to take precedence over identifying and reducing the risks. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Italy)
Confirm this action.
Leaving now will discard your changes.