Linus Torvalds is embracing AI to write Linux kernel code, and some people are having fits. He has a message for them. So do I. Roy Schestowitz, editor of Tux Machines, summed up his reaction to the news as "Linus Torvalds Turns to Slop." In the podcast Pivot to AI, podcaster David Gerard agreed: "Linux kernel goes full AI slop code." Meanwhile, in the Tom's Hardware comments section, commenter "LordVile" wrote: "This is a publicity stunt from his AI overlords [The Linux Foundation] who pay his wage." They followed this by saying this is the "same reason he's flipped-flopped on AI." I've known Linus for a few decades, and I don't take his use of AI as evidence that he's suddenly abandoned his standards. And the very idea that he'd do anything he didn't want to do with Linux on behalf of the Linux Foundation, or anyone else, is ludicrous. I get it, though. There are reasons to be suspicious of AI. I've written about many of them. For instance, AI model collapse, which happens when AI engines learn from other AI models and their ties to the truth fray. It's a very real problem. Not, mind you, that LLMs find the grist for their answer mills from very reliable sources in the first place. Even when AI gets good data, as it does in programming, its owners pay little to no attention to the copyrights and licenses protecting the open source code it picked up its coding tricks from. As for paying for the information it runs on, please! The very idea that Big AI must pay writers, artists, you name it, for using their work is anathema to them. All that said, when it comes to programming, the ship has sailed. AI is becoming part of the programming toolkit, whether its critics like it or not. Why? Because while you still can't vibe code your way into delivering production-quality software, when someone who knows what they're doing, like Torvalds, uses AI, it can be very useful. Anyone who says otherwise is just making the same mistake the Luddites did. Who now, some of you may ask? They were textile workers who attacked machinery in the early 19th century in protest against changes threatening their wages and livelihoods. You may have noticed that while people still weave cloth by hand, industrial production is mechanized. The same is happening now with AI and programming. I think we're about halfway through the process, and by 2030 or so, people programming by "hand" will be about as common as weavers doing it by hand are today. In short, get over it. I don't love it, either. I write for a living, and my business is being crunched too. At least in programming, quality work still counts, no matter how it's done. With writing, though, true AI slop is increasingly the rule, not the exception. Back to Linux: at the Linux Kernel Maintainers Summit in Prague the other week, Sasha Levin, a Linux kernel developer, announced that the maintainers had decided to "deprecate the Assisted-by Tag." That means you no longer need to say if you used AI in your code submissions. That doesn't mean you can turn in slop, though. That code won't pass muster. As Torvalds told me in a note the other day: "I think the whole 'don't use AI for commit messages' kind of argument … Maybe it's well-intentioned, but I think it's entirely misguided. I really think we want competent people to use AI as a tool." Competent is the key word there. Torvalds also wrote: "The 'clueless people using AI' problem is different. I do think we want to discourage that. Not discourage the people who use AI and truly want to learn and truly want to become useful members of the kernel community – but discourage the drive-by patches, and discourage people who just want to feel like they sent a patch and never really wanted to become anything more. We all start clueless, but some people spend the time and effort to become something more." Exactly so. As Torvalds said at Open Source Summit Europe: "I think [vibe-coding is] a wonderful way to find joy in programming. It makes you feel like you're doing something relevant. It allows you, as a new programmer, to do things that you would otherwise have a really hard time with." He added: "I love the concept of AI as a gateway drug" to programming. Besides, AI has already proven very useful for improving Linux code. As long-term Linux kernel maintainer Greg Kroah-Hartman told me back in March: "Months ago, we were getting what we called 'AI slop,' AI-generated security reports that were obviously wrong or low quality." But then, "something happened a month ago, and the world switched. Now we have real reports." It's not just Linux, he continued. "All open source projects have real reports that are made with AI, but they're good, and they're real." True, the maintainers are getting buried in good bug reports now, but as Kroah-Hartman and discussed in Prague, AI bug finders might eventually exhaust the readily discoverable problems, easing the pressure on maintainers. Another AI win is that you can use AI to reverse-engineer Windows drivers for Linux more easily. Christian F.K. Schaller, Red Hat's director of software engineering, created hw-harness while working on a Linux driver for a slide scanner. This open source project provides "tooling for working out how a piece of hardware behaves so that you can write a Linux driver for it." By automating some seriously slow, tedious ways of figuring out what a binary-only driver was doing with the hardware, Schaller has made building Linux drivers from Windows drivers much easier. I know, because I did this myself back in the mid-2000s, and those manual methods are still what people use today. This could go a long way toward fixing one of those lingering annoyances of the Linux desktop: poor or entirely missing hardware drivers. In the meantime, Torvalds told me: "Well, in all fairness, we do clearly have an 'AI problem.' Or rather, we have two independent AI problems: we have a large codebase that AI finds real bugs in, and that adds a lot of work on already fairly overworked maintainers. And then we have people who use AI to generate patches without actually understanding the code in question." He continued: "But I'd argue that these aren't problems with AI itself; they are just problems that are exposed by AI. They are very much both very real problems, and I understand that people can really come to dislike – and even hate – AI due to them, but I do think the underlying issue isn't AI itself." It's how people misuse AI. In the right hands, as the top Linux programmers are showing us, AI can be useful. ®

Britain is threatening subsea cable saboteurs with up to 14 years in prison and unlimited fines, having apparently decided that Victorian-era laws aren't quite up to the job of keeping Russian submarines away from critical infrastructure. The government on Thursday set out plans to overhaul legislation dating back to 1885 and introduce tougher penalties for damaging the underwater cables and pipelines that keep Britain's internet and energy supplies running. According to Whitehall, subsea cables carry around 99 percent of the UK's international data traffic, while underwater pipelines account for 74 percent of its gas supply. Yet much of this infrastructure is protected by laws written when the telegraph was cutting-edge technology. The Submarine Telegraph Act 1885 originally imposed a £100 maximum fine for damaging a cable through culpable negligence. That might have been a reasonable deterrent back then, but it's unlikely to give today's would-be saboteurs much pause. Under the proposals, those who intentionally damage critical subsea energy or telecoms infrastructure could face up to 14 years behind bars. The proposals also set tougher penalties, including unlimited fines, for reckless or negligent damage. Subsea telecoms operators would face new legal duties to identify and manage security risks, while ministers would gain powers to direct companies and cable repair providers to take action where necessary and proportionate to protect national security. The government also wants to regulate fiber-optic sensing technology, which uses subsea cables to detect activity at sea but could pose a security risk if sensitive data falls into hostile hands. Unsurprisingly, Russia features prominently in Whitehall's thinking. In April, British forces exposed a covert Russian submarine operation near critical undersea infrastructure. The operation reportedly involved an attack submarine acting as a decoy while two specialist vessels surveyed Britain's cable routes. "The threats we face have changed dramatically, with suspicious Russian activity around critical undersea infrastructure, yet some of the laws protecting these vital connections date back more than a century," said telecoms minister Ian Murray. The plans aren't entirely new. In May, the government announced its intention to toughen penalties and introduce security obligations for cable operators. Thursday's White Paper spells out the proposed penalties and how far ministers could go in directing operators to act. It also follows warnings from Parliament's Joint Committee on the National Security Strategy, which concluded last year that Britain was insufficiently prepared for a coordinated attack on its subsea infrastructure. MPs and peers warned that government assessments focused too heavily on individual cable failures, rather than what might happen if attackers simultaneously targeted connections to Europe and across the Atlantic. Russian submarines aren't responsible for every severed cable. Fishing boats and ships dragging their anchors do most of the damage, accounting for up to 97 percent of faults, according to previous government estimates. And even when sabotage is suspected, catching those responsible is another matter. Britain already has laws allowing life sentences for serious acts of state-backed sabotage, but they're not much use if nobody can prove who did it. That's rather difficult when the crime scene is at the bottom of the sea. And it might prove equally difficult to extradite suspects from enemy nation states. None of this is law yet. The government has opened a 12-week consultation on the plans, after which ministers will decide how to proceed. Whether the threat of a lengthy prison sentence will trouble Russian submariners is debatable. Even so, after 140 years, Britain's subsea cable laws are finally getting dragged out of the Victorian era. ®

Researchers have developed a new exploit that shows how even Address Space Layout Randomization (ASLR) on an x86-64 server cannot stop the PHP2Shell vulnerability. VulnCheck, which made it available to only the company’s Initial Access Intelligence customers, also warned that threat actors are using AI to find even more ways to attack. The team told us that it’s a “significant advance” because up until now, ASLR has been a major barrier to exploiting PHP2Shell on real-world servers. They don't expect that to hold, though. “Adversaries are clearly spending time (and tokens) on this bug,” Spencer McIntyre, director of exploit development at VulnCheck, told The Register. The PHP2Shell mess grew even bigger on Thursday amid reports of attackers abusing the security flaws days before they were disclosed and UK government websites proactively going dark. Vulncheck's exploit targets CVE-2026-109618, a critical, out-of-memory corruption bug that leads to remote code execution (RCE) in PHP, and part of the PHP2Shell pair alongside CVE-2026-109619. The PHP Foundation officially disclosed and issued patches for both on Wednesday. Overnight, VulnCheck researchers developed what they believe is the first known exploit to achieve remote code execution on ASLR-enabled x86-64 systems with PHP's recommended production configuration. ASLR is a built-in defense against memory-corruption bugs – like PHP2Shell – that randomly arranges memory locations of a program's key data areas. By scrambling these components live, in memory every time a program runs, ASLR prevents an attacker trying to achieve RCE from correctly guessing the target memory address – and thus prevents them from executing malicious code. While VulnCheck has seen “hundreds” of PHP2Shell proof-of-concept repositories on GitHub, “very few contain legitimate, working exploits,” McIntyre told us, adding that this is largely due to ASLR. “There's a significant difference between demonstrating a vulnerability and developing an exploit that can overcome the security protections found in real-world environments,” McIntyre said. “One of the biggest obstacles has been ASLR, a protection designed to make memory corruption vulnerabilities much harder to exploit.” The threat hunters’ new technique, we’re told, bypasses ASLR. It uses a confirmed memory leak chained into RCE on PHP 8.4.26, and they claim it works on x86-64 platforms even with ASLR enabled and PHP’s recommended display_errors=off production configuration. “We haven't identified another public or commercial exploit that achieves this under the same conditions,” McIntyre said. “Developing this capability was far from trivial, but it demonstrates that a major barrier to exploiting PHP2Shell on production-configured systems can be overcome.” VulnCheck says it also works on ARM64, but the RCE is not currently functional on ARM-based systems. This should be a wake-up call to all organizations that, especially now in the era of AI bug hunting and exploit development, “the technical difficulty of exploiting a vulnerability shouldn't be confused with protection against it,” McIntyre said. “Organizations running vulnerable versions of PHP should prioritize patching rather than assume existing memory protections or configuration changes will stop an attack.” ®

GitLab on Wednesday patched a maximum-severity flaw that could allow unauthenticated attackers to execute arbitrary code on self-managed servers under certain conditions. Affected software releases date back a full 12 years - so upgrade to a fixed version now. The integer overflow bug, tracked as CVE-2026-110264, affects regular-expression compilation in GitLab Community Edition (CE) and Enterprise Edition (EE), including versions dating back to GitLab 7.0, released in June 2014. The flaw, “under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression,” the vendor said in its release notes. GitLab released fixes in versions 19.5.1, 19.4.3, and 19.3.6, and backported the patch to versions 19.2.9, 19.1.9, 19.0.10, and 18.11.13. The vendor “strongly recommends” that all organizations running vulnerable software upgrade to a fixed version “as soon as possible.” GitLab-managed infrastructure, including GitLab.com and GitLab Dedicated, remains patched, and the vendor also released two threat detections (here and here) for customers with self-managed instances. Bug hunter Johan Carlsson reported the vulnerability through GitLab’s HackerOne bug bounty program. “For organizations running self-managed GitLab infrastructure, the potential impact is severe,” warned threat-detection firm SOC Prime. “GitLab repositories frequently contain source code, CI/CD configuration, deployment secrets, access tokens, infrastructure definitions, and connections to production environments. Server-level compromise could therefore create opportunities for credential theft, repository manipulation, supply chain attacks, persistence, or lateral movement.” While there’s no indication - yet - of any in-the-wild exploitation attempts, we’d expect criminals to start scanning for vulnerable instances soon. The ongoing PHP chaos may have given defenders a short head-start on this one, but considering the perfect 10 CVSS severity rating and GitLab’s reach into the enterprise - it claims 50 million registered users and more than 50 percent of the Fortune 100 - that’s not going to last long. Last month, attackers started battering another max-severity flaw in the same GitLab CE and EE products just days after the vendor issued a patch, according to the US Cybersecurity and Infrastructure Security Agency and private researchers.®

After embarrassing reports revealed weak private keys, one of which was just a single digit, Indian certification authority eMudhra has decided to take the L and get out of the global SSL/TLS cert game entirely. eMudhra announced Thursday that it was abandoning that arm of its business. Sure, the intense scrutiny heaped on the company was a factor, but the firm also argued that growing compliance costs and competition from free certificate providers had made the business increasingly difficult to justify. “Global SSL/TLS is a small part of eMudhra’s business contributing to about 1 percent of the global revenue,” the company explained, noting that free SSL/TLS cert issuance from large firms and increased compliance and data sovereignty requirements have made it a minor part of the firm’s operation, and one that doesn’t merit so much bad press. “The level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business,” eMudhra explained. “In view of this, after detailed deliberations our board has concluded that withdrawing from global SSL/TLS is the right decision for eMudhra and its shareholders.” An argument could be made that, even if SSL/TLS accounts for just 1 percent of its global revenue, a private CA key with a value of 4 still deserves a thorough public shaming. It’s only been two days since eMudhra’s weak private keys were exposed in public reports, following a report to Mozilla on October 17, and it wasn’t exactly hard for security researchers to recover them: The eight affected private-key values ranged from the number 4 (yes – a plain old number 4), to 56 and 66, to the far more complicated 115, 155, 156, 230, and 237. No quantum computer required to crack those keys. Wow – better save the qubits. This wasn’t just an embarrassing collection of numbers, either: The weak keys belonged to eight intermediate certificate authorities, potentially allowing attackers to forge certificates trusted by systems that hadn’t blocked them. eMudhra, however, maintains that the affected CAs had issued no end-entity certificates. eMudhra quickly went on the defensive about its mind-boggling key-management failure, acknowledging the weak keys while pointing to independent audits and a problem during its key-generation ceremony that it said produced the weak keys alongside the intended strong ones. “A flaw in the key generation ceremony caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys,” the company said the day after the key fiasco was reported. “The weak keys were the ones published to the browser root stores.” Despite that, eMudhra said the relevant certificate infrastructure had undergone two years of independent audits and had been in browser trust lists since mid-2025, raising questions about why the weak keys weren't caught sooner. eMudhra claimed on Thursday that the affected CAs had issued no end-entity certificates, that it had revoked those CAs within 14 hours of discovering the issue, and that neither its infrastructure nor its data had been compromised as a result of its key boo-boo. Still, the incident has given eMudhra another reason to shave off a small part of its business rather than continue facing scrutiny over its certificate operations. It’s still going to issue a root-cause report and fulfill its remaining commitments to browser root programs as it winds down the business. The company said it’ll continue to serve G1 RSA roots until it transitions customers to other certificate issuers, which it will do free of charge. “Revocation and certificate status services will keep running until every issued certificate has expired or been replaced,” the company said. ®

The PHP2Shell security fiasco has forced 32 UK government services offline and left another four partially unavailable as Whitehall scrambles to patch the critical vulnerabilities wreaking havoc across the web. The figures were disclosed in the House of Lords on Thursday, where tech minister Baroness Lloyd of Effra outlined the disruption following the discovery of two critical flaws in PHP. "Currently, the information I have is that 32 government services are unavailable and four are partially unavailable," Lloyd told peers. "That has resulted largely from precautionary measures taken to protect systems while security updates and mitigations are applied." "We are working very carefully with departments to restore the services safely and securely following that remediation activity," she added. Whitehall has not published a full list of affected services, although the Office for Budget Responsibility (OBR) is among those known to have taken their websites offline, rather inconveniently with next week's Budget looming. Peers also raised reports of disruption affecting the DVLA and police services. Britain isn't alone in pulling the plug. Government websites in Germany, France, Belgium, Finland, and the Netherlands have also been taken offline as a precaution, along with Australia's own cybersecurity agency website. Across the Atlantic, the NSA has urged organizations to patch or disconnect vulnerable systems, although the US government has not publicly confirmed any website shutdowns. PHP2Shell comprises two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that could allow unauthenticated attackers to execute code on vulnerable servers. The National Cyber Security Centre (NCSC) warned organizations to patch immediately or consider pulling affected systems offline until they could be fixed. "The NCSC was briefed by OpenAI last week on this potential specific vulnerability and has been working to ensure that disclosure happened in a co-ordinated way with vendors, so there was sufficient preparation to protect customers," Lloyd said. Security firm Calif found one of the PHP bugs using OpenAI's GPT-5.6 Sol model, while Google's Wiz separately uncovered both flaws with the help of AI tools. OpenAI then dug into the vulnerabilities itself and worked with vendors and government agencies to get the word out. The government established a cross-departmental incident response operation before public disclosure, Lloyd said. The NCSC also sent 50,000 warnings to businesses and other organizations. The disruption has spread beyond central government. Liberal Democrat peer Baroness Ludford pointed to several councils whose services had reportedly been taken offline, including Edinburgh, Oxford, Bristol, Lambeth, and Barnet. She questioned why central government and local authorities remain outside the statutory duties proposed under the government's Cyber Security and Resilience Bill, which returns to the Lords on Monday. "We are not currently aware of any confirmed compromise of central government systems resulting from these vulnerabilities," Lloyd told peers, later extending that assessment to the wider UK public sector. AWS says attackers were exploiting the flaws four days before they were publicly disclosed, while Cloudflare has since recorded millions of attempts to weaponize them. ®

In a world full of cyber risk, account takeover has emerged as one of the most insidious of all threats. If an attacker can successfully compromise a legitimate email account, they are then able to pose as a trusted individual or organization without triggering any warnings. Traditional email security will see nothing wrong. From there the threat actor can pick their moment to cause havoc with objectives that range from stealing money, expropriating sensitive data and propagating catastrophic malware. Serious financial loss and a damaged corporate reputation are commonplace outcomes. The typical account takeover lifecycle starts with the bad guys obtaining credentials, usually through the medium of phishing. Generative AI (GenAI) has made it easy for an attacker to trick an unwary individual into giving away login data, perhaps by posing as a colleague or other trusted party or by encouraging them to enter confidential information on a fake login page. You might expect, once a legitimate identity has been successfully compromised, that all hell would immediately break loose. These days the typical account takeover artist is more stealthy and sinister than that, in no rush to act at this early stage since no alarm bells have been triggered. Most will take their time to test out and verify their stolen login data, and see where it might take them. “Conventionally attackers would take over an account and immediately start firing off spam and phishing,” says Dave Baggett, SVP Cybersecurity with software developer Kaseya. “Now they are starting to get clever. They’ll get access to an account and sit tight, watching all the email traffic passing and waiting for an opportune moment to inject themselves into the conversation.” From the inside out Once they’ve figured out an organisation’s weak points and come up with a plan of attack, the bad guys will start to weaponize the compromised email account to target other employees and internal systems. Assuming their motivation is financial, they might be on the hunt for a way into payroll or invoicing databases. But their ultimate aim might lie further afield in the form of the organisation’s customers and suppliers, and that’s when the real nightmare can start. So called outbound phishing offers the criminal a way to assert control over a whole new range of sensitive end points. Victims of outbound phishing are highly vulnerable in the face of what seem to be messages from a trusted partner and ally. It is one thing for an organisation to protect its own email accounts with robust controls like multifactor authentication (MFA), but no one has control over the authentication practices of other parties: “Let’s say we have a customer who we’re protecting,” explains Baggett. “They’re safe, but imagine that they start getting suspicious emails from a third party. Our customer has no idea what is or isn’t protecting that third party. Emails coming from that source might appear to be from a real account, but it could be a hacker typing them.” Given that you can’t run checks on third party organisations, something more sophisticated than regular email security is required. Ideally this would be a GenAI-powered solution that can bring language understanding to bear, able to examine conversation histories in depth to see if something anomalous can be spotted. It makes life even harder for defenders when the bad actor has successfully assumed the identity of somebody senior. If they are impersonating a top-tier manager with an extensive and trusted reputation then they have a powerful asset on their hands. All the trust and goodwill of that senior individual is now inherited by the criminal. Conventional email filtering systems will often be configured to allow senior personnel past certain defensive layers with minimal friction, so as not to restrict important business communications. Recipients of mail from such sources may be disinclined to challenge and report them, should suspicions be raised by the nature of what they are asking for. It takes a bold employee to call out as fraud what seems to be a message from somebody at C-level, especially when the email system has apparently green lighted it as authentic. Bringing the power of AI to bear The heat is on not just for IT departments but for MSPs who have multiple organisations under their protection, many of which will have no real in-house security knowledge of their own. Kaseya’s own research shows just how exposed many are. New approaches are needed that deal with the menace of account takeover before damage can be caused. And should a takeover transpire, consideration must be given to containing its impact before vital data and infrastructure are affected. The good news is that modern tools exist that perform just these tasks. INKY is Kaseya's generative AI-driven email analysis tool. It has capabilities that go well beyond any kind of traditional email security, tuned to detect, through the most subtle and marginal signs, when an email conversation is in the process of being infiltrated. Using techniques such as advanced sender profiling, stylometry and machine learning, INKY is adept at identifying inconsistencies between the known writing patterns of a legitimate employee and the slightly unfamiliar tone of a fake message. It can sniff out that something is wrong, even when message headers seem real, just by spotting the kind of contextual anomalies that expose a phoney message. INKY is especially useful when it comes to third party account takeover. It achieves this by building and maintaining detailed profiles of trusted senders based on technical and behavioural characteristics. Over time it learns what “normal” looks like and can see when a third-party email doesn’t match a sender’s established profile. Containing an attack If a takeover attempt has been successful, there’s more to stemming the damage than just putting a block on a suspect account. By the time of its discovery, a compromised identity may have already led to inroads being made into connected SaaS apps, cloud storage and collaboration tools, widening the possible blast zone well beyond a single email thread. Modern IT environments are a jungle of identity-driven endpoints and gateways, and therefore increasingly difficult to defend against intruders armed with legitimate credentials. To compound matters, when the bad guys have AI at their disposal they are able to treat these SaaS-driven ecosystems as a single attack surface. Defence that relies on a patchwork of individual tools, each created to solve a particular challenge in one silo of the organisation, will not be up to countering this kind of threat. That’s why INKY is configured to work with Kaseya SaaS Alerts, a cloud-based detection and response platform designed to help MSPs and others to monitor and protect business applications. Once INKY has picked up that a mailbox has been hijacked, it isolates the user and blocks outbound mail. It then sends an event to SaaS Alerts so that it can lock down that user's access across the rest of the stack. The tools work as a team, INKY blocking the compromised account and SaaS Alerts preventing the damage from spreading. The power of this partnership comes from INKY’s ability to stream real-time email security telemetry into SaaS Alerts, including inbound analysis results and threat detections, user-reported phishing activity and outbound mail protection events. This type of integration helps to automate real-time threat detection across a complex SaaS ecosystem. “It means if we see suspicious mail going out, we can shut the account down, and take other remedial actions,” says Baggett. “The more you understand the meaning of the mail, the more you can catch.” Smart tools to the rescue The battle against account takeover is never won, and future innovation is always needed. We’ve seen how AI is a dangerous weapon in the hands of the attacker. It’s also a very handy tool for the defender – but there are some qualifications: “You can’t just put every inbound and outbound mail through an LLM since the economics don’t add up,” points out Baggett. “You’ve got to be more clever than that.” One of the most important and cleverest emerging uses for GenAI lies in not simply protecting against account takeover but predicting where weakness might lie, helping to stop a problem before it happens. Baggett believes that the security industry is at the very beginning of being able to use models to predict in this way. An essential preliminary is making sure the many different components that go into securing an organisation can share information with each other. That integration work is underway, an early example being the real time dialogue between INKY Mail Protection System and SaaS Alerts. Next step is a unified data layer where any security component can publish an event in real time, and any other component can subscribe. “We’ll continue to make more integrations of this sort over time,” promises Baggett. “We’re also building a centralised capability for AI. With so many of the different components having their own AI, you need an underpinning platform. We also have a service bureau of Machine Learning experts who can make customised models for different tasks. There’s no sleeping on the job. The volume of attacks is clearly going to increase.” Read more in Kaseya’s Cybersecurity Report here Sponsored by Kaseya