Cybersecurity researchers have disclosed details of a large-scale campaign that has targeted exposed network edge devices such as Fortinet FortiGate and Palo Alto Networks GlobalProtect firewalls.
"Artifacts from this investigation also indicate that operators in this campaign have obtained access to numerous organizations worldwide, and have attempted to further compromise some victims,
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. ®
PHP has warned of another way an attacker could run code on a web server, two days after it shipped emergency fixes for the critical PHP2Shell flaws.
The new issue, assigned CVE-2026-115560, affects only web applications configured in an unusual way, and PHP considers it an unlikely risk.The project is not issuing an emergency fix for it. Instead, it recommends turning off a feature called
The Russian state-sponsored hacking group Sandworm teamed up with another threat actor to carry out a destructive wiping attack targeting a Ukrainian logistics company last year.
According to ESET, the attack involved UAC-0099 (aka Earth Sirrush) obtaining initial access to the target on July 16, 2025, via a spear-phishing email bearing a malware-laced attachment that led to the deployment of
Pillow, the most widely used image library for Python, can be made to run operating system commands on a server by specifying the name of a file it is told to open.
The flaw, CVE-2026-112900, is in the way Pillow handles EPS images, which it opens by passing the file's name to Ghostscript, a separate program it runs to turn the image into pixels, without checking the name first.
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. ®
Malicious Brotli data can make an application on an official build of Node.js run attacker-supplied code, security researchers at Imperva have demonstrated.
Their "Node2Shell" proof of concept ran code on the official Node.js 24.22.0 image for Linux arm64, with no debugger or custom build, by feeding crafted data to the bundled Brotli decoder (CVE-2026-111497). Node.js disclosed the flaw
AI agents paying for API calls with the x402 SDKs could sign a payment for their full balance of a supported token if a malicious API asked for it, security firm V12 said on October 22.
The cause was the SDKs' default client, which set no spending limit until releases on August 18 added one. The risk was limited to agents who automatically signed payments and whose apps set
Threat actors have been observed unsuccessfully attempting to exploit the newly disclosed PHP2Shell vulnerabilities to rope infected systems into a Mirai botnet variant called Potassium, as it emerges that weaponizing the flaws may be harder than previously thought.
The attacks aim to exploit CVE-2026-109618 and CVE-2026-109619 (CVSS scores: 9.2), which can result in unauthenticated remote
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.” ®
Attackers are exploiting a zero-day SQL injection flaw in Arista's VeloCloud Orchestrator (VCO), the central management system for VeloCloud SD-WAN networks, the company said in an advisory on October 22.
The flaw lets anyone who can log in to the orchestrator, even with a read-only customer account, gain operator privileges, the top level of control over it.
For
eMudhra, an Indian certificate authority (CA), will withdraw from its global SSL/TLS certificate business, its board decided on Thursday. The decision came five days after a researcher reported recovering the private keys of eight of its intermediate CA certificates.
eMudhra said it will replace affected customers' certificates with free ones from partners, though its
This week has already been rough for cybersecurity. Critical PHP and GitLab RCE flaws, serious Linux security bugs, compromised eMudhra certificates, a Node.js RCE flaw, a hacked LiteLLM release, and hundreds of hijacked Tor relays. That's a lot to deal with in just a few days. And the week isn't even over yet.
But those big headlines are only half the story. Stolen passwords, exposed
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.®
Linux servers running KSMBD, the kernel's built-in SMB server, are exposed to two publicly reported remote code execution flaws rated 9.0 by Trend Micro's Zero Day Initiative, with no fix yet in the mainline kernel.
One of them, ZDI-CAN-33774, can be triggered before any network authentication. The other, ZDI-CAN-33549, requires the SMB Direct transport and an RDMA-capable network
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. ®
Login
