Networks used to be simple. A perimeter. A data center. A set of rules a single engineer could hold in their head. That world is long gone. Every wave of enterprise transformation – cloud migration, M&A, hybrid multi-cloud, IoT, remote work – added another layer of complexity. Each with its own topology, traffic patterns, and security assumptions. The complexity grew exponentially. And security followed, manually – more policies to author, more configurations to validate, more vendors to manage. The part that doesn’t show up in vendor presentations is that modern network security runs on institutional know-how. It lives in the […]
Attackers are increasingly abusing Microsoft’s decades-old MSHTA utility to stealthily deliver stealers, loaders, and persistent malware through phishing, fake software downloads, and LOLBIN-based attack chains.
IT teams are increasingly overwhelmed by alerts from disconnected systems, forcing responders to manually coordinate investigations during network incidents. This webinar explores how automation and AI-assisted workflows can help reduce response delays and improve operational coordination. [...]
Microsoft says customers in restricted network environments may encounter Windows Update failures after installing the January 2026 optional non-security preview updates. [...]
Among the various tools in the Kaspersky portfolio is a dedicated platform for securing containerized environments. But in this post, I want to talk about Kaspersky Container Security (KCS) — not as a vendor representative, but rather as a member of a team that actively uses this solution in their daily work. Our Product Security Team is responsible for establishing secure development processes across the company. We’re involved in every stage of the software development life cycle, and our priority is helping product teams catch security issues early so they can stay on schedule for their releases. To achieve this, we’ve built several workflows, one of which focuses specifically on container security. That’s exactly where we lean on our own Kaspersky Container Security platform.
Container security solutions are typically viewed first and foremost as image scanners for the container registry. However, Kaspersky Container Security (KCS) is more of a comprehensive security platform for container environments that handles multiple tasks by virtue of its end-to-end integration into the container workflow. While it certainly includes a container image scanning scenario — which is undeniably important — our experience with KCS has shown that its real value becomes apparent when it’s integrated into several points along the workflow at once:
Regular builds
Artifact verification prior to release or deployment
Monitoring of containers already running in the cluster
The baseline scenario: how KCS scans images
At its core, the process is a standard one. KCS checks images for typical container issues: known vulnerabilities, malware, hardcoded secrets, and misconfigurations. However, the scan result isn’t just a single, abstract verdict. The system calculates a risk rating based on the findings, providing a clear picture of the asset’s security posture. In practice, this is incredibly useful because teams don’t just see a “bad image” message; they get a transparent breakdown of exactly what’s driving the risk and what needs to be fixed first.
But that’s not all. KCS works well for scenarios where it’s not enough to just find a problem — you need to tie it to the artifact’s life cycle. When a team is managing hundreds of builds, periodic registry scanning isn’t enough, and it almost always requires manual intervention. You need to know which pipeline introduced the risk, which policies were triggered, and what the next steps are. KCS provides this essential link.
Advanced scenario: CI/CD integration
One lesser-known KCS feature is its full-scale scanning capability within CI/CD pipelines. For our team, this is the most effective way to use KCS. The logic is straightforward: you integrate the scanner into the pipeline, and the scan results appear directly in the execution logs. They’re also sent to the solution’s central console, where they’re logged in a dedicated CI/CD section that links the findings to the artifact name, scan time, pipeline, and severity level.
In a CI/CD environment, you can scan images from tar-archives or directly from Git repositories. Out of the box, it supports GitLab, Jenkins, TeamCity, and GitHub Actions; in practice, KCS can be integrated into any pipeline orchestrator.
Another critical aspect of using KCS in CI/CD involves security policies. Our solution uses a model where policies allow for not just collecting results, but also controlling the behavior of the pipeline itself. This comes in handy for phased rollouts. You can start in audit mode, and then gradually move toward failing builds when secrets, critical misconfigurations, or vulnerabilities are detected. This evolutionary approach generally works better than simply flipping a switch to block it all at once.
How KCS helps in our workflows
We run our own composition analysis system, so we don’t treat KCS as a single source of truth. Instead, it serves as a powerful extra layer in our workflows, and that’s exactly where we find the most value.
While our in-house composition analysis system handles component tracking, dependencies, and code-level risk assessment, KCS excels at securing the container perimeter. It takes care of technical image scanning and CI/CD security, while aggregating reports on container artifacts. It doesn’t conflict with our internal analysis; it reinforces it right where containers receive actual workloads.
This is particularly useful for us in two scenarios. First, it provides early-stage artifact control during development. Second, it acts as a gatekeeper during release acceptance. We no longer debate risks sometime after the release; we catch them at the exact point where the team can still quickly fix a Dockerfile, Helm chart, or config set without a lengthy approval chain.
The way it handles a software bill of materials (SBOM) is also noteworthy. Our system relies primarily on up-to-date, relevant SBOMs. KCS offers modes specifically for processing SBOMs, and can even output scan results in that same format. In this regard, KCS integrates seamlessly with our internal processes, allowing us to fit it into our existing workflows rather than the other way around.
Why KCS is more than just a scanner to us
Its other powerful layer is cluster security. At this stage, KCS evolves beyond being just an image-scanning tool. It features runtime policies for containers and nodes, audit and blocking modes, and a set of security profiles. In practical terms, this means KCS can be used not only to find vulnerabilities within an image, but also to monitor what the container is actually doing once it’s live. Policies can account for image provenance, digital signatures, restrictions on capabilities and volumes, and even the processes and network connections running inside the container.
When a problem is detected, you have the option to log the results in audit mode first rather than blocking the process immediately. In production environments, this is always the smarter move. Another vital tool is ensuring trusted image provenance. KCS supports digital signature verification, which shifts the focus from simply finding CVEs to securing the company’s entire software supply chain.
Reporting capabilities
KCS does more than just display the issues it detects; it serves as a comprehensive reporting source. It can generate reports on images, accepted risks and Kubernetes benchmarks.
Generated reports are available in HTML, PDF, CSV, JSON and XML formats, with specific support for SARIF for detailed reporting — which is ideal for integrating into AppSec workflows. As for the SBOMs mentioned above, the scanning scenarios can output artifacts and results in CycloneDX and SPDX formats, making it easy to plug into existing processes.
Why we continue to use KCS
To put it simply, KCS complements our workflows perfectly — not because it solves every single problem, but because it integrates so effectively into engineering scenarios.
We also appreciate that the product team listens to our feedback. The KCS team actually incorporates our practical operational requests into their development roadmap. For example, deep SBOM integration and specific report types were added to KCS as a direct result of our hands-on experience.
To sum it up, when integrated correctly, Kaspersky Container Security helps cover several areas at once: from basic container scanning, to CI/CD and cluster security. In our experience, it provides real value within a live container ecosystem. You can learn more about the solution on the official KCS page.
A new infostealer variant targets macOS users by spoofing Apple, Microsoft, and Google and then then gets to work searching for victims’ password managers so it can steal all of their credentials and access cryptocurrency wallets such as MetaMask and Phantom. The updated SHub stealer variant is called Reaper, and it uses macOS Script Editor, pre-populated with the malicious payload to execute the malware, according to SentinelOne research engineer Phil Stokes, who documented the attack in a Monday blog. But unlike earlier SHub versions and similar macOS stealer campaigns that rely on ClickFix social engineering tactics to trick the user into pasting a ScriptEditor command into Apple’s Terminal command-line interface, Reaper bypasses Terminal altogether and therefore defeats defenses Apple added to Tahoe 26.4. The attack starts with fake WeChat and Miro installer websites, hosted on a domain designed to instill trust in users by typo-squatting a Microsoft URL: mlcrosoft[.]co[.]com. When a user visits these pages, hidden JavaScript collects a ton of information about their system and browser, including IP address, location, WebGL fingerprinting data, and indicators of virtual machines or VPNs. The attack stops if the victim is located in Russia. Assuming that the machine is located elsewhere and the user clicks on the fake tool installer, they open Apple’s Script Editor app via a sneaky link that’s heavily padded with ASCII art and fake terms to push the malicious command far below the visible portion of the window when it loads. When the victim clicks “Run” in Script Editor, the hidden command executes the malicious AppleScript and displays a popup message purporting to be a security update for Apple’s XProtectRemediator tool. Instead of updating the security tool, however, it calls a curl command to silently download the shell script and it asks the victim to enter their login details – which are scraped and used to decrypt various credentials – and then displays a fake error message. Earlier SHub versions harvested users’ browser data, cryptocurrency wallets, developer-related configuration files, macOS Keychain and iCloud account data, and Telegram session data. Reaper does all of this and more. It includes a filegrabber that searches for files that contain business or financial info in the user’s Desktop and Document folders. That approach is similar to the document-theft functionality seen in Atomic macOS Stealer (AMOS). The script also searches for several desktop cryptocurrency tools including Exodus, Atomic Wallet, Ledger Wallet, Ledger Live, and Trezor Suite. If it finds any, it injects the wallet with malware to ensure continued funds theft. And then, to ensure persistence, it backdoors the infected device by creating a directory structure designed to mimic Google Software Update: ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/. “The LaunchAgent executes the target script GoogleUpdate every 60 seconds,” Stokes explains. “The script functions as a beacon, sending system details to the C2’s /api/bot/heartbeat endpoint.” This ensures the attacker can remotely execute code on the backdoored machine. If the attacker-controlled server sends a “code” payload, the script decodes it, writes it to a hidden file and executes the code with the users’ privileges before deleting the file. The backdoor gives the malware operators “more ways to steal data or pivot to other malicious installs after the initial compromise,” the threat hunter warns. About the only thing it doesn't do is implore the band to add more cowbell. ®
More than 200 individuals were arrested for cybercrime activities during INTERPOL's Operation Ramz, which focused on the Middle East and North Africa. [...]
Data breach notification letters have become a familiar routine. They usually start with “We value your privacy” and offer a year of free credit monitoring. But the most important part is often hidden in the middle:
A list of what actually got out.
A leaked email address is not a leaked admin password. A hashed credential is not a session token. There is no universal post-breach checklist. The right response depends on the data exposed, so read the notice carefully and match your response to the level of exposure.
Many employees already use shadow AI tools at work without security review. Adaptive Security breaks down how teams can build practical AI governance without adding friction for employees. [...]
The Shai-Hulud malware leaked last week is now used in new attacks on the Node Package Manager (npm) index, as infected packages emerged over the weekend. [...]
Another Linux kernel flaw has handed local unprivileged users a way to peek at files they should never be able to read, including root-only secrets such as SSH keys. The bug affects multiple LTS kernel lines from 5.10 upward, although a fix has already landed – and there is now a proposal for reducing the odds of similar surprises in future. What FOSS analytics vendor Metabase memorably dubbed the strip-mining era of open source security continues. This time, the culprit is CVE-2026-46333, a local kernel vulnerability that lets an unprivileged user read files they should not be able to access, including those normally available only to root. An attacker who already has login access to an affected machine could therefore potentially grab SSH keys, password files, or other confidential credentials, as the KnightLi blog explains. Despite its official designation, a demo exploit on GitHub calls it ssh-keysign-pwn. It is not quite as catchy a name as Copy Fail, or Dirty Frag, or indeed Fragnesia, but we feel it is safe to say it hasn't been a good month. According to a report on Linux Stans, it affected LTS kernel versions 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.0. The good news is that it's already been fixed: Linus himself, in commit 31e62c2, called the fix "ptrace: slightly saner 'get_dumpable()' logic." The issue was reported on the oss-security list on Friday by security consultancy Qualys, as noted on X by grsecurity's Brad Spengler. In the same thread, Altan Baig pointed out that the underlying issue was reported by Jann Horn on the Linux Kernel Mailing List way back in 2020. The problem with tracking security reports, which Penguin Emperor Torvalds described recently, is not new, alas. ModuleJail This also seems like a good time to look at what we thought was an interesting new defensive measure, Jasper Nuyens' ModuleJail. The top line of the README summarizes it: The mention of "no AI inside the tool" is arguably something of a giveaway, and you can see a CLAUDE.md file in the repo. Even so, how it works is simple enough. Although Linux has a monolithic kernel, it is modular. When the kernel's source code is compiled, the person or tool building it can choose if each individual component is included (built into the binary), not included at all, or compiled as a module, which can be loaded on the fly as and when it's needed. Since the kernel is mostly device drivers, it's normal for distribution vendors to compile most non-essential components as kernel modules – as the Arch wiki explains. Blacklisting a module just means adding its name to a list of modules not to load. Blacklisting unused modules for added security isn't a new idea. It's in the RHEL 6 documentation, for instance, and a DoHost blog post from last year describes it as a security measure. ModuleJail simply automates the process. It blacklists any modules not currently in use. Probably safe for a server, but rather less ideal for a laptop or machine where you need to plug in new hardware on the fly. Connecting a USB headset, say, is quite different from plugging one into a headphone socket. While a device with a jack plug uses your existing sound controller, by connecting a USB one, you're effectively adding a new sound controller – just one that happens to be connected over USB. ModuleJail mentions that its approach avoids changing the initramfs. An initramfs, like an initrd, is a file containing a temporary RAM disk, so that a generic kernel can find and load the drivers it needs for the particular box it's running on – even before it can find the machine's SSD and mount the root partition. Back in the 1990s, as grumpy old graybeards such as this vulture recall, recompiling your kernel was a standard part of periodic system maintenance. One benefit of building the kernel customized for your own computer was eliminating the need for an initramfs. If all the drivers are built in, there's no need for this temporary stage, although as the ArchWiki notes, this does limit some advanced features, which, for instance, systemd uses. We would love to see some of the systemd-free distros incorporate such automatic ModuleJail-style identification of essential modules, and use it to build a custom kernel on the fly, then banish the use of initramfs. (Maybe just keep the all-options-enabled installation kernel around as an emergency fallback.) Aside from a few special cases such as OpenZFS, this should work on most hardware – and make life simpler, quicker, and perhaps slightly more secure. ®
The TanStack team has documented security measures and proposals following a damaging breach last week, including the possibility of making pull requests (PRs) by invitation only - a break from the open-contribution model that defines most open source projects. The attack used code from the Shai-Hulud worm, published by malware outfit TeamPCP, which can extract secrets from memory used by GitHub Actions. It began with a PR that triggered an automatic workflow via TanStack's use of the pull_request_target feature, causing the malicious code to be built and run by a GitHub Action, poisoning a cache used across the entire repository. The TanStack team said that its workflow used a pattern GitHub warns against: pull_request_target id intended for PRs that "do not require dangerous processing, say building or running the content of the PR." Since the attack, TanStack has removed all use of pull_request_target from its continuous integration (CI) pipeline, disabled caches used by pnpm (a Node.js package manager) and GitHub Actions, pinned actions to commit SHA (Secure Hash Algorithm) hashes rather than retargetable tags, and disabled use of text messages for 2-factor authentication. The TanStack repository also now uses a feature of pnpm 11 called minimumReleaseAge, which requires dependencies to have been published for a set period before they can be installed. The idea is that compromised packages are usually detected and removed before that period completes. A more drastic proposal is closing the ability for external contributors to open pull requests at all. "We are absolutely not going closed source," the team said, but it could put in place a mechanism where contributions begin with an issue or discussion, and a PR can be submitted only by invitation. TanStack acknowledged that it would be a radical step to take as "open PRs are part of how a lot of us became maintainers in the first place." It might not be necessary if the repository can be hardened enough that malicious PRs cannot cause damage. It is a debate that maintainers of other open source projects will watch with interest. Supply chain security is a huge issue, but making pull requests invitation-only could hurt projects by deterring contributions. Another aspect of this is the extent to which GitHub itself is to blame. "Cache scoping in GitHub Actions shouldn't silently bridge fork PRs and base-repo branches," said the TanStack team.®
Exploit attempts are already hammering a newly disclosed NGINX bug dubbed "NGINX Rift," proving once again that attackers read patch notes faster than most admins. Researchers at VulnCheck said they are seeing active exploitation tied to CVE-2026-42945, a heap buffer overflow flaw affecting both NGINX Open Source and NGINX Plus that was disclosed last week after apparently sitting unnoticed for 18 years. VulnCheck's Patrick Garrity said the company observed exploitation activity on its canary systems "just days after the CVE was published." "An unauthenticated attacker can crash the NGINX worker process by sending crafted HTTP requests," he said. "On servers with ASLR disabled – which, of course, is extremely unlikely – code execution is possible." Researchers at Depthfirst disclosed the bug last week, saying the flaw had been sitting in NGINX's rewrite module since 2008. The vulnerability, nicknamed "NGINX Rift," was assigned a CVSS score of 9.2. According to F5, which acquired NGINX in 2019, the flaw can be triggered by specially crafted HTTP requests under certain server configurations. In most cases, the result is a crashed worker process and a forced restart, though systems running without standard Linux memory protections could potentially face code execution. A public proof-of-concept exploit appeared the same day patches dropped, which helps explain why researchers started seeing exploitation attempts almost immediately. In practice, turning this into reliable remote code execution takes a pretty specific setup. The target server must be running a specific rewrite configuration, attackers need enough knowledge of that setup to exploit it correctly, and ASLR must also be disabled on the host system. Security researcher Kevin Beaumont noted that while the bug is real, modern Linux defaults significantly reduce the likelihood of successful real-world RCE. "Regarding CVE-2026-42945 in nginx – no modern (or even old) Linux distribution runs nginx without ASLR," Beaumont said. "So, cool, sweet technical vuln – it's valid – but the RCE apocalypse ain't coming." Even so, VulnCheck said Censys scans surfaced roughly 5.7 million internet-exposed NGINX servers running potentially vulnerable versions, which means patching teams everywhere just inherited another very long week. ®
The Polish government is urging public officials and "entities within the National Cybersecurity System" to stop using Signal, directing them to instead use an encrypted messenger developed by a leading Polish research organization. In an announcement on Friday, the government stated that Signal comes with security risks, including social engineering attacks orchestrated by advanced persistent threat (APT) groups. "National-level Computer Security Incident Response Teams (CSIRTs) have identified phishing campaigns conducted by APT groups linked to hostile state agencies," the announcement says. "These attacks target, among others, public figures and government employees." Offering examples of these social engineering campaigns, the government said attackers impersonate Signal support staff and abuse this perceived trust to take over victims' accounts. Attackers trick users into opening malicious links by sending messages designed to create a sense of urgency, such as those supposedly informing them of their account being blocked. Successful attempts can expose victims' phone numbers and, crucially, messages sent between government officials, potentially threatening national security. A more detailed advisory cited "recent security incidents" related to Signal as reasons for the change. It didn't specify what these recent attacks were, or even who was behind them, but it can be reasonably assumed that the Polish government was indirectly referencing Russia's phishing attempts against both Signal and WhatsApp, which were revealed in March. Dutch intelligence agencies AIVD and MIVD reported a "large-scale" campaign targeting their own government officials, noting that some attacks were successful. "The Russian hackers have likely gained access to sensitive information," the AIVD and MIVD said, adding that successful attacks were carried out on government bods as well as journalists. Beyond Signal support staff impersonation, the agencies said the attacks can also involve outsiders persuading victims to surrender their verification codes or PINs, or abusing the platform's Linked Devices feature via QR codes to take control of accounts. The FBI, CISA, and the German information security department issued near-identical warnings. The alternative Poland announced the launch of mSzyfr Messenger in March, saying it was designed for use by public administration entities, those involved in the National Cybersecurity System, and others to be decided by the government. Developed by the Ministry of Digital Affairs and the Scientific and Academic Computer Network – National Research Institute (NASK), mSzyfr was touted by the government as "the first secure instant messenger fully under Polish jurisdiction." It does, however, rely on multi-factor authentication (MFA) provided by US megacorps. Microsoft is the recommended option, but users can also opt for Google or FreeOTP. Further, if users want to retain access to messages even after logging out of the platform, they must set up a recovery key, which the installation manual suggests storing in a password manager. That undercuts the government's emphasis on Polish jurisdiction somewhat, since many popular password managers are either foreign-owned or open source. An FAQ document for mSzyfr states that the messenger is built with a privacy-by-design philosophy, and explicitly notes that neither WhatsApp nor Signal fits this description. It also claimed the US-based platforms are not GDPR-compliant. The mSzyfr app is not publicly available. Only individuals working for approved organizations are able to receive invites to join the platform. It replaces Swiss-founded Threema, which the Polish government began endorsing for state officials and law enforcement in 2022, but data such as messages cannot be transferred because of the apps' encrypted nature. All Threema users should expect to receive an invite to mSzyfr in the near future, if they have not already. The Register asked Signal to comment on Poland's announcement, but it did not immediately respond. It did, however, recently address security concerns raised by various intelligence agencies last week, introducing new warnings and alerts inside the platform to help users weed out potential impostors and bad actors. ®
Britain's F-35 fighter fleet is set to carry US-made glide bombs as an interim measure until delayed F-35 software updates from Lockheed Martin add support for the SPEAR 3 mini-cruise missile intended for the aircraft. The news comes in an official response from the Ministry of Defence (MoD) to Parliament's Public Accounts Committee (PAC), which published a scathing report last year on the MoD's management of the F-35 program. That report noted that the stealth fighter force lacks essential capabilities, one of which is a stand-off weapon to attack ground targets from a safe distance. The SPEAR missile is intended to fulfil this requirement, but although it is ready and passed test firings in 2024, the F-35 is not currently able to operate it. This capability should have been delivered by now through the Block 4 software update from F-35 prime contractor Lockheed Martin, but this has met with a series of delays. It is now expected in 2031, five years behind schedule. One of the PAC's recommendations was that the MoD should set out in the Defence Investment Plan (DIP) how it will ensure a stand-off capability until SPEAR 3 is fully integrated onto the aircraft. Permanent Secretary at the MoD Jeremy Pocklington wrote back in a letter that approval has been given to proceed with a Foreign Military Sales (FMS) procurement of the precision-guided munition, Small Diameter Bomb (SDB II). "This acquisition will provide the F-35 with an interim stand-off capability until the introduction of SPEAR 3 into service," he stated. SDB II, designated GBU-53/B StormBreaker in US service, is a roughly 200-pound (93 kg) bomb with fold-out wings to allow it to glide to a target up to 69 miles (111 km) away. It has a tri-mode seeker in the nose that lets it use radar, infrared, or laser tracking to home in. Other criticisms leveled at the MoD were that it lacked suitably qualified engineers, and the department's pattern of delaying purchases to meet annual budget targets, which the PAC claimed has the effect of inflating total program costs while reducing operational capacity. Pocklington conceded that not enough spares were available to support the F-35 squadrons aboard aircraft carrier HMS Prince of Wales during the eight-month Operation Highmast deployment last year. "The surge to 24 F-35B aircraft during Operation HIGHMAST exceeded the Afloat Spares Pack capacity of 12. This was mitigated by supplementing with the Deployable Spares Pack [designed for land-based deployments] and taking additional spares from the RAF Marham Base Spares Pack," he wrote. "The Lightning Force is collaborating closely with the Royal Navy to optimise joint scheduling between home and embarked operations, given the current limitation of two front-line squadrons. The Department also plans to double the capacity of the Afloat Spares Pack and procure an additional Deployable Spares Pack for land operations, subject to the DIP." In response, PAC chair Sir Geoffrey Clifton-Brown MP commented on the "entirely unacceptable incompetence that flies in the face of any kind of sensible planning from the Ministry of Defence." "At the heart of any military planning is sound logistics. The UK sent an aircraft carrier with 24 F-35 fighter jets on it to the Middle East – with not enough spare parts to support them." "In an increasingly dangerous world, our military and the country need more than this half-baked approach from the MoD. Our brave fighting men and women, before being sent into potential harm's way, must have absolute certainty that they are well-supported in their equipment, with clear and reliable supply lines," he added. Pocklington's letter also said a short-term reduction in the availability of F-35 aircraft was likely due to the MoD stepping up corrosion awareness and prevention practices. While corrosion can be an issue for all aircraft, this is especially true for those operated from carriers, and it can also impact the F-35's radar-defeating stealth capabilities. The PAC report had noted that the MoD is behind in delivering a UK Aircraft Signature Assessment Facility, needed to check that the F-35's stealth technology is still doing its job and has not been compromised. On the lack of qualified engineers, Pocklington claimed that steps were being taken to address this by increasing available posts to 168. "The RAF has plans in place to fill its remaining engineering posts by 2032. This date is driven by the amount of time (up to three years) it takes to make engineers fully competent on an aircraft type," he said, adding that "the number of personnel recruited into the Engineering Profession, who are now in the training system, has already increased." However, the government's Defence Investment Plan (DIP) was due in autumn 2025, but there is currently no official publication date for it, despite the fact that many key projects are in limbo until it is delivered. ®
Mozilla has warned Britain not to turn VPNs into collateral damage in the government's increasingly desperate hunt for ways to stop kids dodging Online Safety Act age checks. In a submission to the Department for Science, Innovation and Technology's "Growing up in the online world" consultation, Mozilla argued that VPNs are "essential privacy and security tools" used by millions of ordinary people, from those securing public Wi-Fi and remote work traffic to journalists, activists, and other vulnerable users. "VPNs serve as critical privacy and security tools for users across all ages," said Svea Windwehr, policy manager at Mozilla. "By hiding users' IP addresses, VPNs help protect users' location, reduce tracking and avoid IP-based profiling." Windwehr added that people rely on VPNs for everything from connecting remotely to school or work networks to avoiding censorship and "simply protecting their privacy and security online." The filing lands in the middle of an increasingly strange UK debate where privacy tools are being recast as a threat to online safety enforcement. VPN usage in the UK surged almost immediately after Online Safety Act age checks started rolling out last year, as users scrambled to avoid handing sensitive identity data to adult websites and platforms demanding facial scans or ID verification. Child safety advocates and officials then turned their attention to VPNs themselves, with the Children's Commissioner for England even suggesting the government should explore ways to stop children from using them altogether. Mozilla's response argues the government is chasing the wrong target. The company pointed to research from Internet Matters suggesting that relatively few children use VPNs in the first place, and that only a small minority use them specifically to bypass age restrictions. Mozilla instead argued that most successful workarounds involve fake birth dates, borrowed accounts, weak age assurance systems, or laughably fragile facial estimation tools that children have reportedly fooled with drawn-on facial hair. Mozilla also pointed out a central problem with age-gating VPNs: users would first need to hand over personal information before accessing software intended to reduce tracking and data collection. Britain is not the only country suddenly developing strong opinions about VPNs. Denmark recently floated anti-piracy legislation broad enough to trigger fears that VPN usage itself could become legally risky, before ministers hurriedly insisted nobody was trying to ban VPNs. Across Europe, VPNs are being treated less like routine security software and more like an obstacle to enforcement as users turn to them to bypass restrictions. Unfortunately for regulators, the technology industry appears to be moving in the opposite direction. Mozilla has already been testing built-in VPN functionality directly inside Firefox, joining a wider browser trend toward integrating privacy features that previously required separate software. Blocking standalone VPN apps is one thing, but trying to untangle VPN functionality from modern browsers is a much bigger problem. Mozilla's submission repeatedly argues Britain is drifting toward "safety through surveillance" instead of addressing the recommendation systems, engagement algorithms, and platform incentives that actually drive online harms. ®
Login
