Tag Archives: zero day

PaperCut NG/MF Critical Zero-Day Exploited in the Wild

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/etr-papercut-ng-mf-critical-zero-day-exploited-in-the-wild

Overview

On August 27, 2026, PaperCut Software published an urgent security advisory stating that it is investigating active exploitation of a vulnerability affecting PaperCut NG and PaperCut MF. PaperCut has confirmed customer incidents and is treating the issue as a security emergency. At the time of writing, the vulnerability has not been assigned a CVE identifier, and PaperCut has not publicly disclosed a CVSS score, vulnerability class, authentication requirements, or the technical details of the exploit path.

PaperCut NG and PaperCut MF are print management platforms commonly deployed within enterprise, education, and other organizational environments. Because the PaperCut Application Server provides web-accessible administrative and application functionality, organizations with servers exposed to the public internet should prioritize remediation and access restriction.

PaperCut stated in its advisory that information supplied by a university customer’s security team and digital forensics and incident response team enabled its security response team to reproduce the vulnerability in PaperCut NG and PaperCut MF. On August 28, 2026 at 02:10 AEST, PaperCut released emergency patches for PaperCut NG and PaperCut MF versions 25 and 26.

PaperCut has been targeted in the past; in 2023, CVE-2023-27350 was broadly exploited in the wild by multiple threat-actor groups, including ransomware operators. This prior history increases the urgency organizations should address this new zero-day with.

PaperCut currently considers all versions of PaperCut NG and PaperCut MF potentially impacted. Customers operating internet-accessible PaperCut Application Servers should take immediate action even if no suspicious activity has been observed.

Technical overview

The vulnerability is an authentication bypass that lets attackers invoke privileged PaperCut components. This can be leveraged to reconfigure an external database lookup. When this lookup is triggered, malicious SQL can be executed, resulting in remote code execution.

PaperCut uses the Apache Tapestry framework, whose “complex direct” request format can identify one page to display and a different page containing the component to execute. PaperCut validates access only to the displayed page. By selecting either the public Error page or Exception page for display, an attacker can bypass authentication while invoking administrative components belonging to ConfigEditor or UserList.

The attack uses HTTP POST requests to the following URIs (Note that the path segment with the value 1 shown below can be any value for this path segment, and the Error path segment may also be the Exception path segment):

/app?service=direct/1/Error/ConfigEditor/quickFindForm
/app?service=direct/1/Error/ConfigEditor/$Form
/app?service=direct/1/Error/UserList/$QuickFind.$Form

The first two URIs provide unauthenticated access to PaperCut’s configuration editor. The third can invoke a user or card search that triggers the configured external database lookup.

An attacker first uses the ConfigEditor requests to modify four external user-lookup settings:

user-lookup.db-driver
user-lookup.db-url
user-lookup.id-to-username-sql
user-lookup.enabled

These settings normally allow administrators to connect PaperCut to an external card database. After bypassing authentication, however, the attacker can configure them with a malicious JDBC connection and a malicious SQL statement.

By leveraging PaperCut’s bundled Apache Derby database driver and supplying a Derby CALL statement that activates its foreignViews feature, Derby opens an attacker-controlled H2 JDBC URL. H2 processes an inline INIT statement that creates a JavaScript-backed database trigger. PaperCut includes the Nashorn JavaScript engine, allowing that trigger to start an operating-system process. However it is expected that other mechanisms to execute an arbitrary command can also be used instead of Nashorn. Finally, the attacker submits a search through the forged UserList request. This activates the external lookup and executes the malicious SQL.

Mitigation guidance

Organizations running PaperCut NG or PaperCut MF should prioritize patching on an emergency basis, particularly where the PaperCut Application Server is accessible from the public internet.

PaperCut has released emergency patches for PaperCut NG and PaperCut MF versions 25 and 26. 

The vendor notes that these builds have not undergone their normal release process and are intended as emergency fixes for customers with public-facing servers that cannot otherwise sufficiently mitigate exposure. An emergency patch for version 24 is still in development at the time of the vendor’s latest update.

PaperCut recommends that administrators immediately restrict web access to trusted IP addresses only, such as internal corporate network ranges. Firewall rules, network access controls, reverse-proxy restrictions, or equivalent measures should be used to prevent untrusted internet hosts from reaching PaperCut web interfaces.

Please read the PaperCut security advisory for the latest remediation guidance, updated indicators of compromise, and additional release information.

Artifacts/Evidence Sources and IOCs

For detection and forensic analysis, PaperCut has identified several preliminary artifacts and evidence sources that may indicate compromise.

  • Application activity: Alerts from intrusion-detection, endpoint-security, or network-monitoring products involving the PaperCut Application Server, particularly suspicious post-exploitation activity associated with pc-app.exe.

  • Log integrity: Missing, unexpectedly truncated, or deleted PaperCut server.log files.

  • PaperCut server.log entries:

    • ERROR No suitable driver found for jdbc:no:x

    • ERROR DatabaseUtils – Database error looking up cardID: VALUES CAST

PaperCut has not yet published validated network-based indicators such as malicious IP addresses, domains, or URLs.

The vendor specifically warns that the absence of these indicators should not be interpreted as evidence that a system has not been affected.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to this new PaperCut zero-day, with an authenticated vulnerability check expected to be available in the August 28 (today’s) content release.

Updates

  • August 28, 2026: Initial publication.

Microsoft Threatening Security Researcher

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/06/microsoft-threatening-security-researcher.html

An anonymous security researcher called “Nightmare Eclipse” has been publishing a series of significant security exploits against Microsoft Windows—including one that breaks BitLocker. Microsoft has threatened legal action against the researcher. Lots of recriminations are being traded back and forth.

Zero-Day Exploit Against Windows BitLocker

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/zero-day-exploit-against-windows-bitlocker.html

It’s nasty, but it requires physical access to the computer:

The exploit, named YellowKey, was published earlier this week by a researcher who goes by the alias Nightmare-Eclipse. It reliably bypasses default Windows 11 deployments of BitLocker, the full-volume encryption protection Microsoft provides to make disk contents off-limits to anyone without the decryption key, which is stored in a secured piece of hardware known as a trusted platform module (TPM). BitLocker is a mandatory protection for many organizations, including those that contract with governments.

Slashdot thread. And here’s Nightmare-Eclipse’s GitHub account.

DarkSword Malware

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/05/darksword-malware.html

DarkSword is a sophisticated piece of malware—probably government designed—that targets iOS.

Google Threat Intelligence Group (GTIG) has identified a new iOS full-chain exploit that leveraged multiple zero-day vulnerabilities to fully compromise devices. Based on toolmarks in recovered payloads, we believe the exploit chain to be called DarkSword. Since at least November 2025, GTIG has observed multiple commercial surveillance vendors and suspected state-sponsored actors utilizing DarkSword in distinct campaigns. These threat actors have deployed the exploit chain against targets in Saudi Arabia, Turkey, Malaysia, and Ukraine.

DarkSword supports iOS versions 18.4 through 18.7 and utilizes six different vulnerabilities to deploy final-stage payloads. GTIG has identified three distinct malware families deployed following a successful DarkSword compromise: GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER. The proliferation of this single exploit chain across disparate threat actors mirrors the previously discovered Coruna iOS exploit kit. Notably, UNC6353, a suspected Russian espionage group previously observed using Coruna, has recently incorporated DarkSword into their watering hole campaigns.

A week after it was identified, a version of it leaked onto the internet, where it is being used more broadly.

This news is a month old. Your devices are safe, assuming you patch regularly.

Claude Mythos Has Found 271 Zero-Days in Firefox

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/claude-mythos-has-found-271-zero-days-in-firefox.html

That’s a lot. No, it’s an extraordinary number:

Since February, the Firefox team has been working around the clock using frontier AI models to find and fix latent security vulnerabilities in the browser. We wrote previously about our collaboration with Anthropic to scan Firefox with Opus 4.6, which led to fixes for 22 security-sensitive bugs in Firefox 148.

As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week’s release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation.

As these capabilities reach the hands of more defenders, many other teams are now experiencing the same vertigo we did when the findings first came into focus. For a hardened target, just one such bug would have been red-alert in 2025, and so many at once makes you stop to wonder whether it’s even possible to keep up.

Our experience is a hopeful one for teams who shake off the vertigo and get to work. You may need to reprioritize everything else to bring relentless and single-minded focus to the task, but there is light at the end of the tunnel. We are extremely proud of how our team rose to meet this challenge, and others will too. Our work isn’t finished, but we’ve turned the corner and can glimpse a future much better than just keeping up. Defenders finally have a chance to win, decisively.

They’re right. Assuming the defenders can patch, and push those patches out to users quickly, this technology favors the defenders.

News article.

AI Found Twelve New Vulnerabilities in OpenSSL

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/02/ai-found-twelve-new-vulnerabilities-in-openssl.html

The title of the post is”What AI Security Research Looks Like When It Works,” and I agree:

In the latest OpenSSL security release> on January 27, 2026, twelve new zero-day vulnerabilities (meaning unknown to the maintainers at time of disclosure) were announced. Our AI system is responsible for the original discovery of all twelve, each found and responsibly disclosed to the OpenSSL team during the fall and winter of 2025. Of those, 10 were assigned CVE-2025 identifiers and 2 received CVE-2026 identifiers. Adding the 10 to the three we already found in the Fall 2025 release, AISLE is credited for surfacing 13 of 14 OpenSSL CVEs assigned in 2025, and 15 total across both releases. This is a historically unusual concentration for any single research team, let alone an AI-driven one.

These weren’t trivial findings either. They included CVE-2025-15467, a stack buffer overflow in CMS message parsing that’s potentially remotely exploitable without valid key material, and exploits for which have been quickly developed online. OpenSSL rated it HIGH severity; NIST‘s CVSS v3 score is 9.8 out of 10 (CRITICAL, an extremely rare severity rating for such projects). Three of the bugs had been present since 1998-2000, for over a quarter century having been missed by intense machine and human effort alike. One predated OpenSSL itself, inherited from Eric Young’s original SSLeay implementation in the 1990s. All of this in a codebase that has been fuzzed for millions of CPU-hours and audited extensively for over two decades by teams including Google’s.

In five of the twelve cases, our AI system directly proposed the patches that were accepted into the official release.

AI vulnerability finding is changing cybersecurity, faster than expected. This capability will be used by both offense and defense.

More.

LLMs are Getting a Lot Better and Faster at Finding and Exploiting Zero-Days

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/02/llms-are-getting-a-lot-better-and-faster-at-finding-and-exploiting-zero-days.html

This is amazing:

Opus 4.6 is notably better at finding high-severity vulnerabilities than previous models and a sign of how quickly things are moving. Security teams have been automating vulnerability discovery for years, investing heavily in fuzzing infrastructure and custom harnesses to find bugs at scale. But what stood out in early testing is how quickly Opus 4.6 found vulnerabilities out of the box without task-specific tooling, custom scaffolding, or specialized prompting. Even more interesting is how it found them. Fuzzers work by throwing massive amounts of random inputs at code to see what breaks. Opus 4.6 reads and reasons about code the way a human researcher would­—looking at past fixes to find similar bugs that weren’t addressed, spotting patterns that tend to cause problems, or understanding a piece of logic well enough to know exactly what input would break it. When we pointed Opus 4.6 at some of the most well-tested codebases (projects that have had fuzzers running against them for years, accumulating millions of hours of CPU time), Opus 4.6 found high-severity vulnerabilities, some that had gone undetected for decades.

The details of how Claude Opus 4.6 found these zero-days is the interesting part—read the whole blog post.

News article.

Patch Tuesday and the Enduring Challenge of Windows’ Backwards Compatibility

Post Syndicated from Adam Barnett original https://www.rapid7.com/blog/post/ve-patch-tuesday-windows-backwards-compatibility-challenge

Introduction

If you received an email with the subject “I LOVE YOU” and an attachment called “LOVE-LETTER-FOR-YOU.TXT”, would you open it? Probably not, but back in the year 2000, plenty of people did exactly that. The internet learned a hard lesson about the disproportionate power available to a university dropout with some VBScript skills, and millions of ordinary people suffered the anguish of deleted family photos or even reputational damage as the worm propagated itself across their entire Outlook address book.

In the quarter century since ILOVEYOU rampaged across global networks, cybersecurity has moved from a niche topic to an “everyone” problem, and many users are wary of all sorts of threats. In recent years, the increasing ubiquity and urgency of AI adoption across the business landscape has attracted the attention of both security researchers and threat actors.

Of course, recency bias and shiny object fixation are real. Even as AI and automation continue to drive down time to known exploitation (TTKE), an attacker who abuses a traditional exploit chain to achieve SYSTEM privileges on a sensitive server still has the keys to the kingdom.

Wormable remote code execution (RCE) vulnerabilities remain rare, but well over half of the 25 exploited-in-the-wild zero-day vulnerabilities published by Microsoft during 2025 provided attackers with elevation of privilege opportunities on Windows assets. Some of those flaws are older than the iPhone, let alone ChatGPT.

Microsoft’s decades-long commitment to backwards compatibility creates a conveyor belt supply of déjà vu vulnerabilities. Ultimately, the most pressing threats faced by defenders managing Microsoft estates remain essentially unchanged. Rather than a new wave of AI-related flaws, the chief danger stems from the towering tech debt within core Windows components.

A whirlwind tour of exploited-in-the-wild Microsoft vulnerabilities (2025 edition)

If we really want to know which Microsoft vulnerabilities will provide the most value to attackers in 2026, we should ask a threat actor. Since that might prove difficult to arrange, we’ll do the next best thing: review vulnerabilities exploited in the wild during 2025.

Chart-exploited-in-the-wild-eitw-microsoft-by-vulnerable-component-rapid7.png
Chart 1: Exploited-in-the-wild Microsoft vulnerabilities, by vulnerable component

January: The great escape

The vast Microsoft ecosystem has something for everyone, whether customer or threat actor. Patch Tuesday January 2025 brought us a trio of exploited-in-the-wild Hyper-V kernel vulnerabilities. By September 2025, at least one plausible public proof-of-concept (PoC) for CVE-2025-21333 was published by a vulnerability researcher who apparently shares a name with a Kazakhstani Olympic gymnast. The only safe assumption is that a well-resourced threat actor could develop a private exploit far in advance of that.

Starting from a child VM or Windows Sandbox, exploitation first requires setting out a banquet of benign requests for the hypervisor, delivered via the Hyper-V Virtualization Service Provider (VSP). The goal: mass-allocating objects to arrange large swathes of hypervisor memory in a predictable pattern (aka “heap feng shui”). Next, the attacker sends a malicious request with an oversized buffer, which an unpatched VSP merrily copies into kernel memory, overwriting the header of the adjacent object, whose relative position is now easily surmised. Once the kernel subsequently references the artfully corrupted sibling object, execution as SYSTEM jumps to a portion of memory where the attacker has planted shellcode to exfiltrate a token. The compromised hypervisor could be anything from a developer laptop running a malicious container all the way up to enterprise private cloud infrastructure.

So far, January 2025 is the only time that Microsoft has ever published vulnerabilities in the Hyper-V VSP. Generally speaking, a significant degree of sophistication is required to develop successful exploits of this nature. This goes double if the name of the game is stealth and stability, since a wave of unexplained BSOD events on critical production infrastructure tends to attract blue team attention. Still, once a viable proof of concept hits the public internet, ransomware crews will fold it into their toolkits, and someone, somewhere, is either sitting on an unknown Hyper-V VSP exploit, or hard at work creating the next one.

February: Socket to me

It’s hard to imagine a modern computer without storage or networking capabilities. In fact, it’s hard to imagine a computer from several decades ago without storage or networking. Microsoft is now middle-aged, and that means that buried deep within your shiny new PC are a variety of architectural decisions and logic paths born in the 1980s. If this sounds far-fetched, take a minute to find yourself a fully-patched Windows 11 25H2 machine, and then try to rename any file or directory CON, NUL or PRN. I’ll wait.

Generally speaking, user-mode applications are prevented from wreaking havoc on the kernel through a careful separation of concerns. On Windows, when a user mode application wants to communicate over the network, it talks to WinSock, which in turn talks to the ancillary function driver (AFD), which sits on the kernel side, and coordinates with the kernel network drivers which handle the actual traffic. The AFD is a security boundary between user space and kernel space, and it must be universally accessible to local processes, because even a browser tab in a sandbox needs to make network calls. Any defect in the way AFD parses input from user space can thus provide a way to influence the kernel in unexpected ways. A number of advanced exploit development courses, including offerings from SANS and OffSec, cover AFD in detail.

chart-Windows-AFD-vulnerabilities-timeline-rapid7.png
Chart 2: Windows AFD vulnerabilities timeline, 2021-2025

Patch Tuesday February 2025 brought us CVE-2025-21418, which Microsoft credited to Anonymous. We don’t know whether the unnamed tipster provided evidence of exploitation in the wild, or whether Microsoft threat hunters subsequently tracked down their own trail of suspicious bread crumbs, but notorious threat actors such as North Korea’s Lazarus are known to be enthusiastic students of AFD exploits. With several high-profile zero-day vulnerabilities emerging from AFD from late 2024 onwards, it tracks that Microsoft subsequently published and patched a cluster of AFD vulnerabilities in the latter half of 2025.

March: File system shenanigans

Any defenders who had enjoyed a quieter start to the year were rudely awakened by Patch Tuesday March 2025, when six exploited-in-the-wild vulnerabilities all dropped at once. Exploitation of most of the zero-day vulnerabilities published in March starts with the user mounting a malicious Virtual Hard Disk (VHD) image or plugging in a malicious USB stick so that the attacker can exploit a weakness in a filesystem driver, including NTFS and FastFAT.

Remember that information security training which asked you to imagine finding a USB stick with an “IMPORTANT (CONFIDENTIAL)” label on the floor outside the office? The one which asked if you would A) plug the mystery stick into your work PC B) use your boss’ personal laptop in case the files are business critical C) try it in all the PCs in the office until someone asks you to stop or D) report it immediately to the security officer? This is why.

Meanwhile, the true villain of the month was almost certainly CVE-2025-24983, a no-user-interaction-required elevation of privilege vulnerability in the Win32 kernel subsystem. At the time, we pondered why Windows 11 and Server 2019 onwards didn’t receive patches for what looks like a fairly severe vulnerability, but since Microsoft is gradually reimplementing portions of the kernel in memory-safe Rust, we can hope that the vulnerability simply doesn’t exist in modern Windows.

April: Common Log File System driver vulns are quite common

If anyone ever corners you at a party and talks at length about the Ancillary Function Driver as a bounteous source of elevation of privilege vulnerabilities, you will probably have to concede that they are technically correct. While your options include “doing a lap” and then climbing out of the bathroom window, the power move here is to hold your ground, and point to the Common Log File System driver as a far richer vein of exploitable goodness.

As of Patch Tuesday April 2025, CLFS boasts almost twice the number of total vulnerabilities over the past five years vs. AFD, and more than double the number of known-exploited zero-day vulnerabilities. It really is the gift which keeps on giving.

chart-windows-CLFS-vulnerabilities-timeline-rapid7.png
Windows CLFS vulnerabilities timeline, 2021-2025

It makes sense that something like the Ancillary Function Driver lives in kernel space. After all, something has to sit inside the perimeter to marshall all those network requests from dozens of Chrome tabs. What about the Common Log File System driver though?

It would be tempting to imagine that anything which simply handles log files shouldn’t need direct kernel access at all. When exploring this concept, it’s useful to understand that not only was CLFS designed a long time ago, when high performance in user mode was harder to achieve than it is today, but also that CLFS is much more than simply a means to interact with log files. CLFS is the home of still-essential building blocks like Transactional NTFS (TxF), first introduced almost 25 years ago in Windows Vista, which provides a means for applications to guarantee the integrity of data on disk.

For the past several years, Microsoft has strongly recommended that developers avoid the use of TxF, and while Microsoft is gradually providing modern alternatives to TxF functionality, essential Windows functions such as Windows Update still rely on it to manage critical file integrity. Moreover, CLFS is more than just TxF, and is so tightly integrated into Windows that it’s here to stay for the foreseeable future.

May: The month of expectation, wishes, hope, and classic Windows zero-days [1]

A few days after Patch Tuesday May 2025, Satya Nadella took to the stage at Microsoft Build 2025 to pitch his vision of the open agentic web, although exactly who this version of the future would be open to remains an open question, like: What if a cloud email service was vulnerable to a zero-click prompt injection attack, but could also now buy things with your credit card?

While critical reception for the open agentic web has been mixed, threat actors will be glad of the new attack surface. Meanwhile, defenders worried about in-the-wild exploitation were hard at work patching some more frequent fliers, including another pair of CLFS vulnerabilities and an MSHTML/Trident arbitrary code execution bug. That last one will be familiar to regular Patch Tuesday watchers, but it might come as a surprise to anyone who thought Internet Explorer had gone to live on a nice farm upstate years ago.

The Ancillary Function Driver made another appearance, although it couldn’t quite summon the same main character energy this time around. The May 2025 episode of “AFD vulns exploited in the wild” offered elevation to Administrator, rather than SYSTEM, and a lower exploit code maturity rating. We can always be grateful for small mercies.

[1]: With apologies to Emily Brontë.

June: I’m afraid I can’t let you do that, WebDAV

Windows archeologists and internet users of a certain age may remember WebDAV, a standard originally dreamed up to support interactivity on the web. It was employed by versions of Microsoft Exchange up to and including 2010 to handle interactions with mailboxes and public folders.

Surprising no-one, Windows still more or less supports WebDAV, and it was only a matter of time before that turned out to be a bit of a problem, in the form of CVE-2025-33053 published as part of Patch Tuesday June 2025. Microsoft acknowledged Check Point Research (CPR) on the advisory; CPR in turn attributes exploitation to an APT (Advanced Persistent Threat), which they track as the objectively cool-sounding Stealth Falcon, an established threat actor with a long-running interest in governments and government-adjacent entities across the Middle East and beyond.

June 2025 also saw the publication of CVE-2025-32711, a critical information disclosure vulnerability in Microsoft 365 Copilot. Microsoft is not aware of exploitation in the wild. The researchers named it EchoLeak, describing it as “the first real-world zero-click prompt injection exploit in a production LLM system,” although other researchers arguably got there first.

EchoLeak relies on hidden white-text-on-white-background instructions in an email, which are then ingested into the LLM via RAG (Retrieval-Augmented Generation) when the user asks an entirely pedestrian question (e.g. “Summarize my emails from the past two days”) which requires Copilot to scan the inbox. The malicious instructions have two parts: First, dig up some juicy info, and then retrieve an image from an attacker-controlled server with the sensitive data exfiltrated as a URL parameter.

EchoLeak circumvented Copilot’s Content Security Policy by making the request via a trusted Microsoft service: a now-patched Teams image preview proxy. History suggests that attackers will find other ways out of the walled garden. The Microsoft advisory makes a virtue of minimalism by providing almost no information about the nature of the vulnerability, although Microsoft is surely to be commended for assigning CVEs for cloud service vulnerabilities.

July: The call is coming from inside the intranet

When Patch Tuesday July 2025 came and went without a single exploited-in-the-wild vulnerability published, many people may have breathed a sigh of relief. Possibly this was a valid move, at least for anyone not responsible for a SharePoint instance.

SharePoint defenders will remember July as the month of ToolShell, an actively-exploited vulnerability chain in SharePoint which Microsoft published out of band ten days after Patch Tuesday. Out of band patches for Microsoft flagship products are rare, since they inevitably cause downstream disruption. Once MSTIC publicly attributes exploitation to two Chinese nation-state actors, that line has been crossed.

The vulnerability described by the out-of-band CVE-2025-53770 turned out to be a bypass for the patch introduced by CVE-2025-49704 earlier in the month, which was itself a response to a successful Pwn2Own Berlin entry from May.

August: It’s almost too quiet

Microsoft was not aware of exploitation in the wild for any of the vulnerabilities published as part of Patch Tuesday August 2025. SharePoint admins may have been dealing with the fallout from last month’s ToolShell and bracing for a possible repeat, but August might otherwise have made for an eerily quiet month. Still, the Windows implementation of Kerberos managed to cough up a publicly-disclosed elevate-to-domain-admin vulnerability.

Separately, we learned that simply saving a JPEG could be enough to hand an attacker RCE capabilities, because the internet never sleeps. If the vulnerable codepath had been within JPEG decoding, rather than encoding, this one could have been the biggest vuln of the year.

September: Almost too quiet, part 2

Patch Tuesday September 2025 was the second month in a row with no known-exploited vulnerabilities, but vuln spotters will appreciate that this month saw the publication of a fairly rare beast: a Microsoft vulnerability with a perfect(?) CVSS v3 base score of 10.0, albeit a cloud service vulnerability discovered by Microsoft and patched prior to publication. No customer action required, but also no customer verification possible, and since the impacted cloud service was Azure Networking, the blast radius could have been stupendous.

October: Dial M for exploitation

These days, there are plenty of seasoned IT professionals who don’t even know what a dialup modem negotiation song sounds like, simply because broadband has been around for that long. For younger readers, “broadband” is what we used to call “internet fast enough that you don’t have to wait to download a single email attachment”.

By this point, we all know where this is going: Windows still ships with modem capabilities well beyond their sell-by date, and someone found a good old elevation of privilege vulnerability. The vulnerable fax modem driver was developed almost 30 years ago by a long-defunct third party, and Microsoft has now taken uncharacteristically bold action by removing it from Windows altogether, perhaps recognizing that traditional landlines are no longer available at all in many places. Are there other fax modem drivers still lurking in Windows? You betcha.

Patch Tuesday October 2025 also marked the end of Windows 10, unless you count the cash-for-patches Extended Security Updates (ESU) program.

November: Kernel vuln? Popcorn time

Patch Tuesday November 2025 included an exploited-in-the-wild vulnerability in the Windows kernel itself. While the advisory was light with details, exploitation of CVE-2025-62215 led to elevation to SYSTEM, presumably via a complex bit of memory management three card monte. Those kernel Rust rewrites can’t come soon enough.

December: A cloud of suspicion

After a year filled with variations of the same old exploitable vulns, it might almost be refreshing to consider the altogether more modern-sounding exploited-in-the-wild vulnerability published on Patch Tuesday December 2025. CVE-2025-62221 describes an elevation of privilege vulnerability in the Windows Cloud Files Mini Filter Driver.

On Windows, a file or directory can contain a reparse point, a collection of user-controlled metadata designed to be interpreted by a file filter driver. An example would be a file which appears present in a local folder, but where the actual contents of the file are stored remotely on OneDrive. The user double-clicks on the file, the file filter driver intercepts the request, reads the metadata, and calls out to OneDrive, while the user gets the experience of opening the file as though it had been stored locally. Of course, the file filter driver needs kernel access to perform its duties. Find an exploitable flaw in the way a file filter driver parses the metadata, and you can trick it into doing things like overwriting protected system files.

What’s next?

Everything gets faster, including bad things

As Rapid7 has observed repeatedly, time to known exploitation for widely-exploited vulnerabilities has been shrinking year-on-year. By 2022, the time to exploitation after public disclosure for some of the most notable security vulnerabilities was as low as 24 hours. With exploit development now widely augmented by automation and AI, there is every reason to suppose that the window will continue to shrink further.

Threat actors will stay best friends with elevation of privilege vulns

A wormable unauthenticated RCE vulnerability remains the scariest scenario, but mercifully these are historically rare. The one-two combo of minimally-privileged initial access and local privilege escalation presents a much more clear and present danger in most modern threat models. Sure, you could parachute in from a helicopter, abseil down from the roof, and crawl through an air vent to steal the diamond, but why bother when you could simply tailgate a delivery driver, and then distract a maintenance worker while you swipe their all-access keycard?

AI is here to stay, but tech debt is the real killer

In 2026, Microsoft will regularly publish AI-related vulnerabilities, and AI-wielding threat actors will hammer Microsoft’s cloud services. Blue teams managing significant Windows estates will still spend more time worrying about on-prem vulnerabilities where the root cause is a classic software engineering snafu.

Final thoughts

Arguably the biggest takeaway from 2025 is that the more things change, the more they stay the same. The scariest Microsoft vulnerabilities tend to emerge from the same few familiar places: core Windows components with codebases older than many of the humans who rely on them.

Microsoft’s wildly successful business model is founded on a decades-long insistence on ironclad backwards compatibility. Why? Enterprise customers with deep pockets and deeper catalogues of ancient business applications. These retro capabilities come at a high price: a supervolcano of tech debt potentially unmatched in all of human history, and a seemingly endless supply of sort-of-new but depressingly familiar vulnerabilities.

For anyone responsible for defending a significant Microsoft footprint in 2026, tomorrow’s biggest problem remains today’s secrets exposed by yesterday’s software design choices.

Zero-Day Exploit in WinRAR File

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/zero-day-exploit-in-winrar-file.html

A zero-day vulnerability in WinRAR is being exploited by at least two Russian criminal groups:

The vulnerability seemed to have super Windows powers. It abused alternate data streams, a Windows feature that allows different ways of representing the same file path. The exploit abused that feature to trigger a previously unknown path traversal flaw that caused WinRAR to plant malicious executables in attacker-chosen file paths %TEMP% and %LOCALAPPDATA%, which Windows normally makes off-limits because of their ability to execute code.

More details in the article.

Microsoft SharePoint Zero-Day

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/07/microsoft-sharepoint-zero-day.html

Chinese hackers are exploiting a high-severity vulnerability in Microsoft SharePoint to steal data worldwide:

The vulnerability, tracked as CVE-2025-53770, carries a severity rating of 9.8 out of a possible 10. It gives unauthenticated remote access to SharePoint Servers exposed to the Internet. Starting Friday, researchers began warning of active exploitation of the vulnerability, which affects SharePoint Servers that infrastructure customers run in-house. Microsoft’s cloud-hosted SharePoint Online and Microsoft 365 are not affected.

Here’s Microsoft on patching instructions. Patching isn’t enough, as attackers have used the vulnerability to steal authentication credentials. It’s an absolute mess. CISA has more information. Also these four links. Two Slashdot threads.

This is an unfolding security mess, and quite the hacking coup.

Most of 2023’s Top Exploited Vulnerabilities Were Zero-Days

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/11/most-of-2023s-top-exploited-vulnerabilities-were-zero-days.html

Zero-day vulnerabilities are more commonly used, according to the Five Eyes:

Key Findings

In 2023, malicious cyber actors exploited more zero-day vulnerabilities to compromise enterprise networks compared to 2022, allowing them to conduct cyber operations against higher-priority targets. In 2023, the majority of the most frequently exploited vulnerabilities were initially exploited as a zero-day, which is an increase from 2022, when less than half of the top exploited vulnerabilities were exploited as a zero-day.

Malicious cyber actors continue to have the most success exploiting vulnerabilities within two years after public disclosure of the vulnerability. The utility of these vulnerabilities declines over time as more systems are patched or replaced. Malicious cyber actors find less utility from zero-day exploits when international cybersecurity efforts reduce the lifespan of zero-day vulnerabilities.

AIs Discovering Vulnerabilities

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/11/ais-discovering-vulnerabilities.html

I’ve been writing about the possibility of AIs automatically discovering code vulnerabilities since at least 2018. This is an ongoing area of research: AIs doing source code scanning, AIs finding zero-days in the wild, and everything in between. The AIs aren’t very good at it yet, but they’re getting better.

Here’s some anecdotal data from this summer:

Since July 2024, ZeroPath is taking a novel approach combining deep program analysis with adversarial AI agents for validation. Our methodology has uncovered numerous critical vulnerabilities in production systems, including several that traditional Static Application Security Testing (SAST) tools were ill-equipped to find. This post provides a technical deep-dive into our research methodology and a living summary of the bugs found in popular open-source tools.

Expect lots of developments in this area over the next few years.

This is what I said in a recent interview:

Let’s stick with software. Imagine that we have an AI that finds software vulnerabilities. Yes, the attackers can use those AIs to break into systems. But the defenders can use the same AIs to find software vulnerabilities and then patch them. This capability, once it exists, will probably be built into the standard suite of software development tools. We can imagine a future where all the easily findable vulnerabilities (not all the vulnerabilities; there are lots of theoretical results about that) are removed in software before shipping.

When that day comes, all legacy code would be vulnerable. But all new code would be secure. And, eventually, those software vulnerabilities will be a thing of the past. In my head, some future programmer shakes their head and says, “Remember the early decades of this century when software was full of vulnerabilities? That’s before the AIs found them all. Wow, that was a crazy time.” We’re not there yet. We’re not even remotely there yet. But it’s a reasonable extrapolation.

EDITED TO ADD: And Google’s LLM just discovered an exploitable zero-day.

Using LLMs to Exploit Vulnerabilities

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/06/using-llms-to-exploit-vulnerabilities.html

Interesting research: “Teams of LLM Agents can Exploit Zero-Day Vulnerabilities.”

Abstract: LLM agents have become increasingly sophisticated, especially in the realm of cybersecurity. Researchers have shown that LLM agents can exploit real-world vulnerabilities when given a description of the vulnerability and toy capture-the-flag problems. However, these agents still perform poorly on real-world vulnerabilities that are unknown to the agent ahead of time (zero-day vulnerabilities).

In this work, we show that teams of LLM agents can exploit real-world, zero-day vulnerabilities. Prior agents struggle with exploring many different vulnerabilities and long-range planning when used alone. To resolve this, we introduce HPTSA, a system of agents with a planning agent that can launch subagents. The planning agent explores the system and determines which subagents to call, resolving long-term planning issues when trying different vulnerabilities. We construct a benchmark of 15 real-world vulnerabilities and show that our team of agents improve over prior work by up to 4.5×.

The LLMs aren’t finding new vulnerabilities. They’re exploiting zero-days—which means they are not trained on them—in new ways. So think about this sort of thing combined with another AI that finds new vulnerabilities in code.

These kinds of developments are important to follow, as they are part of the puzzle of a fully autonomous AI cyberattack agent. I talk about this sort of thing more here.

On the Zero-Day Market

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/05/on-the-zero-day-market.html

New paper: “Zero Progress on Zero Days: How the Last Ten Years Created the Modern Spyware Market“:

Abstract: Spyware makes surveillance simple. The last ten years have seen a global market emerge for ready-made software that lets governments surveil their citizens and foreign adversaries alike and to do so more easily than when such work required tradecraft. The last ten years have also been marked by stark failures to control spyware and its precursors and components. This Article accounts for and critiques these failures, providing a socio-technical history since 2014, particularly focusing on the conversation about trade in zero-day vulnerabilities and exploits. Second, this Article applies lessons from these failures to guide regulatory efforts going forward. While recognizing that controlling this trade is difficult, I argue countries should focus on building and strengthening multilateral coalitions of the willing, rather than on strong-arming existing multilateral institutions into working on the problem. Individually, countries should focus on export controls and other sanctions that target specific bad actors, rather than focusing on restricting particular technologies. Last, I continue to call for transparency as a key part of oversight of domestic governments’ use of spyware and related components.

Another Chrome Vulnerability

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/05/another-chrome-vulnerability.html

Google has patched another Chrome zero-day:

On Thursday, Google said an anonymous source notified it of the vulnerability. The vulnerability carries a severity rating of 8.8 out of 10. In response, Google said, it would be releasing versions 124.0.6367.201/.202 for macOS and Windows and 124.0.6367.201 for Linux in subsequent days.

“Google is aware that an exploit for CVE-2024-4671 exists in the wild,” the company said.

Google didn’t provide any other details about the exploit, such as what platforms were targeted, who was behind the exploit, or what they were using it for.

New iPhone Exploit Uses Four Zero-Days

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/01/new-iphone-exploit-uses-four-zero-days.html

Kaspersky researchers are detailing “an attack that over four years backdoored dozens if not thousands of iPhones, many of which belonged to employees of Moscow-based security firm Kaspersky.” It’s a zero-click exploit that makes use of four iPhone zero-days.

The most intriguing new detail is the targeting of the heretofore-unknown hardware feature, which proved to be pivotal to the Operation Triangulation campaign. A zero-day in the feature allowed the attackers to bypass advanced hardware-based memory protections designed to safeguard device system integrity even after an attacker gained the ability to tamper with memory of the underlying kernel. On most other platforms, once attackers successfully exploit a kernel vulnerability they have full control of the compromised system.

On Apple devices equipped with these protections, such attackers are still unable to perform key post-exploitation techniques such as injecting malicious code into other processes, or modifying kernel code or sensitive kernel data. This powerful protection was bypassed by exploiting a vulnerability in the secret function. The protection, which has rarely been defeated in exploits found to date, is also present in Apple’s M1 and M2 CPUs.

The details are staggering:

Here is a quick rundown of this 0-click iMessage attack, which used four zero-days and was designed to work on iOS versions up to iOS 16.2.

  • Attackers send a malicious iMessage attachment, which the application processes without showing any signs to the user.
  • This attachment exploits the remote code execution vulnerability CVE-2023-41990 in the undocumented, Apple-only ADJUST TrueType font instruction. This instruction had existed since the early nineties before a patch removed it.
  • It uses return/jump oriented programming and multiple stages written in the NSExpression/NSPredicate query language, patching the JavaScriptCore library environment to execute a privilege escalation exploit written in JavaScript.
  • This JavaScript exploit is obfuscated to make it completely unreadable and to minimize its size. Still, it has around 11,000 lines of code, which are mainly dedicated to JavaScriptCore and kernel memory parsing and manipulation.
  • It exploits the JavaScriptCore debugging feature DollarVM ($vm) to gain the ability to manipulate JavaScriptCore’s memory from the script and execute native API functions.
  • It was designed to support both old and new iPhones and included a Pointer Authentication Code (PAC) bypass for exploitation of recent models.
  • It uses the integer overflow vulnerability CVE-2023-32434 in XNU’s memory mapping syscalls (mach_make_memory_entry and vm_map) to obtain read/write access to the entire physical memory of the device at user level.
  • It uses hardware memory-mapped I/O (MMIO) registers to bypass the Page Protection Layer (PPL). This was mitigated as CVE-2023-38606.
  • After exploiting all the vulnerabilities, the JavaScript exploit can do whatever it wants to the device including running spyware, but the attackers chose to: (a) launch the IMAgent process and inject a payload that clears the exploitation artefacts from the device; (b) run a Safari process in invisible mode and forward it to a web page with the next stage.
  • The web page has a script that verifies the victim and, if the checks pass, receives the next stage: the Safari exploit.
  • The Safari exploit uses CVE-2023-32435 to execute a shellcode.
  • The shellcode executes another kernel exploit in the form of a Mach object file. It uses the same vulnerabilities: CVE-2023-32434 and CVE-2023-38606. It is also massive in terms of size and functionality, but completely different from the kernel exploit written in JavaScript. Certain parts related to exploitation of the above-mentioned vulnerabilities are all that the two share. Still, most of its code is also dedicated to parsing and manipulation of the kernel memory. It contains various post-exploitation utilities, which are mostly unused.
  • The exploit obtains root privileges and proceeds to execute other stages, which load spyware. We covered these stages in our previous posts.

This is nation-state stuff, absolutely crazy in its sophistication. Kaspersky discovered it, so there’s no speculation as to the attacker.

Email Security Flaw Found in the Wild

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/11/email-security-flaw-found-in-the-wild.html

Google’s Threat Analysis Group announced a zero-day against the Zimbra Collaboration email server that has been used against governments around the world.

TAG has observed four different groups exploiting the same bug to steal email data, user credentials, and authentication tokens. Most of this activity occurred after the initial fix became public on Github. To ensure protection against these types of exploits, TAG urges users and organizations to keep software fully up-to-date and apply security updates as soon as they become available.

The vulnerability was discovered in June. It has been patched.

Critical Vulnerability in libwebp Library

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/09/critical-vulnerability-in-libwebp-library.html

Both Apple and Google have recently reported critical vulnerabilities in their systems—iOS and Chrome, respectively—that are ultimately the result of the same vulnerability in the libwebp library:

On Thursday, researchers from security firm Rezillion published evidence that they said made it “highly likely” both indeed stemmed from the same bug, specifically in libwebp, the code library that apps, operating systems, and other code libraries incorporate to process WebP images.

Rather than Apple, Google, and Citizen Lab coordinating and accurately reporting the common origin of the vulnerability, they chose to use a separate CVE designation, the researchers said. The researchers concluded that “millions of different applications” would remain vulnerable until they, too, incorporated the libwebp fix. That, in turn, they said, was preventing automated systems that developers use to track known vulnerabilities in their offerings from detecting a critical vulnerability that’s under active exploitation.