Tags: #Claude | #Cyber Crime | #Suchmaschine

Read more of this story at Slashdot.

Read more of this story at Slashdot.

The post Enhanced developer tools on the Microsoft Store appeared first on Windows Developer Blog.

A remote code execution vulnerability has been reported in Microsoft Windows Notepad. The vulnerability is due to improper validation of links in Markdown files.

A remote attacker could exploit this vulnerability by enticing the victim to download and interact with a malicious file. Successful exploitation of this vulnerability could result in the execution of arbitrary commands in the security context of the victim's account.

The Vulnerability

Microsoft Windows comes with a default text-editing application called Windows Notepad. Historically, this application offered only minimal editing features. However, modern versions of Windows include an improved and extended Notepad by default. This new version supports multiple file formats, Markdown rendering, and Copilot-enhanced features.

Markdown is a lightweight markup language that allows users to create formatted text using a simple syntax. It is widely used for writing documents, blog posts, and README files. It supports a wide range of formatting options, including (but not limited to) headers, styled text, numbered and bulleted lists, and links. Markdown supports two main link formats: standard and inline. The standard link format is:

          [link-name](link/path)

When rendered, only the link text ("link-name") is shown to the user.

The inline links use the following format:

          <link/path>

When rendered, they are transformed into the equivalent standard link:

          [link/path](link/path)

A remote code execution vulnerability has been reported in Microsoft Windows Notepad. The vulnerability is due to improper validation of links when handling Markdown files.

When Notepad opens a file, if the application detects that the file requires special rendering (in this case, Markdown), the input file is tokenized. Tokenization in this context means splitting the raw file text into a sequence of small, recognizable pieces ("tokens") that the renderer can process one by one. Detection is performed based on the file extension. Only the ".md" extension was found to trigger Markdown rendering, as the application uses a fixed string comparison to determine whether Markdown should be rendered by calling sub_1400ED5D0(). Markdown files are rendered token by token.

Function sub_140170F60() handles clicking on links in Markdown files. It filters the link value, and passes it to ShellExecuteExW() call.

The filtering performed on the link is found to be insufficient, as it allows using malicious crafted protocol URIs, such as "file://" and "ms-appinstaller://", to execute arbitrary files in the security context of victim. ShellExecuteExW() uses the configured protocol handlers and may expose additional exploitable protocols depending on the system configuration.

A remote attacker could exploit this vulnerability by enticing the victim to download a malicious crafted Markdown file, open it, and click on a malicious link. Successful exploitation of this vulnerability could result in the execution of arbitrary commands in the security context of the victim's account.

Notes
• Files using the ".md" file extension are not registered to be opened by Notepad by default. However, when opened manually in Notepad, they are rendered as Markdown, which allows the vulnerability to be triggered.
• Any "\\" sequences are converted to "\" in the attacker-controlled link path prior to passing it to the ShellExecuteExW() call.

Source Code Walkthrough

The following code snippet was taken from Notepad.exe version 11.2508. Comments added by TrendAI researchers have been highlighted.

In sub_140170F60():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following application protocols that can be used to deliver an attack to exploit this vulnerability:
• FTP, over ports 21/TCP, 20/TCP
• HTTP, over port 80/TCP
• HTTPS, over port 443/TCP
• IMAP, over port 143/TCP
• NFS, over ports 2049/TCP, 2049/UDP, 111/TCP, 111/UDP
• POP3, over port 110/TCP
• SMTP, over ports 25/TCP, 587/TCP
• SMB/CIFS, over ports 139/TCP, 445/TCP

The detection device must inspect traffic transferring a Markdown file with the file extension ".md". If such a file transfer is found, the detection device must search the file content for links.

The detection device must check whether the link paths contain the strings "file:" or "ms-appinstaller:".

If "file:" was found, the detection device must search the Markdown file contents using the following case-insensitive regular expression:

(\x3C|\[[^\x5d]+\]\()file:(\x2f|\x5c\x5c){4}

If "ms-appinstaller:" was found, the detection device must search the Markdown file contents using the following case-insensitive regular expression:

(\x3C|\[[^\x5d]+\]\()ms-appinstaller:(\x2f|\x5c\x5c){2}

If any of the regular expressions matches, the link contains a path to a remote resource. The traffic must be considered malicious; an attack exploiting this vulnerability is likely underway. This guidance should also detect the public PoC that was recently posted on GitHub.

Notes

•  The string matches are case-insensitive.
•  The detection guidance is based on the vendor-provided patch. However, the patch restricts the links to local-only files and HTTP(S) URIs, which may result in a huge number of false positives. Because of that, the detection guidance focuses on formats that may access and execute remote files. Due to that, it may result in false negatives.
•  The vulnerable function uses the configured protocol handlers and may expose additional exploitable protocols depending on the system configuration.

Conclusion

This vulnerability was patched by Microsoft in the February 2026 release cycle. They note no workarounds but do list user interaction as a prerequisite to exploitation. To fully remediate the vulnerability, the proper action is to test and deploy the provided vendor patch.

Special thanks to Nikolai Skliarenko and Yazhi Wang of the TrendAI Research team for providing such a thorough analysis of this vulnerability. For an overview of TrendAI Research services please visit https://go.trendmicro.com/tis/vulnerabilities.html.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Adobe Patches for February 2026

For February, Adobe released nine bulletins addressing 44 unique CVEs in Adobe Audition, After Effects, InDesign, Substance 3D Designer, Substance 3D Stager, Adobe Bridge, Substance 3D Modeler, Lightroom Classic, and the Adobe DNG Software Development Kit (SDK). The largest update here is for After Effects, which fixes 13 Critical and two Important rated bugs. The patch for Substance 3D Designer is on the larger side with seven fixes, but only two of those are Critical. On the other hand, the fix for Substance 3D Stager corrects five Critical-rated bugs that could lead to code execution. The Audition patch fixes six bugs, but only one is Critical.

The other patches are smaller in size. The fix for the Adobe DNG Software Development Kit (SDK) corrects two Critical and two Important-rated bugs. The InDesign patch fixes three bugs, but only one is Critical. The update for Adobe Bridge fixes two Critical bug that could lead to code execution. The patch for Lightroom Classic addresses a single Critical bug, and the release is wrapped up with a patch for Substance 3D Modeler that fixes a single, Important-rated memory link.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release, and all of the updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for February 2026

This month, Microsoft drops 58 new CVEs in Windows and Windows components, Office and Office Components, Azure, Microsoft Edge (Chromium-based), .NET and Visual Studio, GitHub Copilot, Mailslot FS, Exchange Server, Internet Explorer (!), Power BI, Hyper-V Server, and the Windows Subsystem for Linux. Counting the third-party and Chromium updates listed in the release, it brings the total number of CVEs to 62. One of the bugs in the Windows Graphics component was submitted through the ZDI program. Five of these bugs are rated Critical, two are rated Moderate, and the rest are rated Important in severity.

It’s typical to see this number of CVEs released in February, but the number of bugs under active attack is extraordinarily high. Microsoft lists six bugs being exploited at the time of release, with three of these listed as publicly known. Last month only had a single bug being exploited, although there were twice as many CVEs patched. We’ll see if we’re on our way to another “hot exploit summer” as we saw a few years ago or if this is just an aberration.

Let’s take a closer look at some of the more interesting updates for this month, starting with the bugs under active attack:

-    CVE-2026-21510 - Windows Shell Security Feature Bypass Vulnerability
This bug is listed as a security feature bypass, but it could also be classified as code execution. An attacker can bypass Windows SmartScreen and Windows Shell security prompts to execute code on a target system. This bug is also listed as publicly known, but Microsoft doesn’t say where. There is user interaction here, as the client needs to click a link or a shortcut file. Still, a one-click bug to gain code execution is a rarity. Definitely test and deploy this fix quickly.

-    CVE-2026-21514 - Microsoft Word Security Feature Bypass Vulnerability
This bug also requires user interaction in the form of opening a Word document, but that’s all that’s required to bypass protections to dangerous COM/OLE controls. Thankfully, the Preview Pane is not an attack vector here. However, users are well known to open lots of documents they receive in e-mail. This bypass could also result in code execution if the right COM/OLE control is hit. This is also listed as publicly known, so add this to the list to test and deploy quickly.

-    CVE-2026-21519 - Desktop Window Manager Elevation of Privilege Vulnerability
This is the second month in a row that a DWM was listed as being exploited in the wild. That leads me to believe the first patch didn’t completely resolve the vulnerability. Same as last month, this bug allows attackers to run code with SYSTEM privileges. Bugs of this type are typically paired with a code execution bug to take over a system. As always, Microsoft offers no indication of how widespread these exploits may be.

-    CVE-2026-21533 - Windows Remote Desktop Services Elevation of Privilege Vulnerability
Don’t let the word “Remote” in the title fool you – this is a local bug that allows attackers to run code with SYSTEM privileges. It’s interesting that Microsoft lists “Improper privilege management” as the root cause for this issue. If the system is running Remote Desktop Services, it’s probably a juicy target for attackers to move laterally after an initial breach. Add this one to the list of patches to test and deploy immediately.

-    CVE-2026-21513 - Internet Explorer Security Feature Bypass Vulnerability
Although long gone by many measurements, IE does still exist on Windows systems, and calling it always results in a vulnerability somehow. This bug manifests similarly to the Shell bug above, as it requires user interaction but could result in code execution. The bypass here is simply the ability to reach IE, which shouldn’t be possible. Again, test and deploy this fix quickly.

-    CVE-2026-21525 - Windows Remote Access Connection Manager Denial of Service Vulnerability
It’s unusual to see DoS bugs being used in active attacks, but that’s what we have here. A null pointer deref in the Windows Remote Access Connection Manager allows an unauthorized attacker to deny service locally. Most null pointer derefs cause the application or service to crash, but it’s not clear if it will automatically restart. I would exercise caution and patch quickly either way.

Here’s the full list of CVEs released by Microsoft for February 2026:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Moving on to the Critical-rated bugs, the patch for Azure Front Door sounds frightening, but Microsoft has already fixed the bug and is just now documenting it. That’s also true for the bugs in Azure Arc and Azure Function. There are two Critical-rated bugs in the ACI Confidential Containers. The first allows a container escape while the second discloses secret tokens and keys. Either way, you’ll want to handle those quickly.

Taking a look at the other code execution vulnerabilities in this month’s release, we start with a frightening looking bug in Azure SDK for Python that has the highest CVSS this month of 9.8. A remote, unauthenticated attacker code gain code execution on an affected system via a maliciously crafted continuation token. It’s not clear why this isn’t rated Critical, but I would treat it as such. The three bugs in Hyper-V are actually local open-and-own bugs that require a user to open a malicious file on an affected system. That’s also true for the bug in Notepad. The bug in Power BI is confusing, because Microsoft says it requires authentication and could lead to an attacker running code as an authenticated user. There’s the poorly named “Azure Local Remote Code Execution Vulnerability”, but it requires a machine-in-the-middle (MitM) to exploit. The bug in Defender for Endpoint Linux is restricted to local subnets, but you’ll need to enable auto provisioning to get the patch. The final code execution bugs addressed this month are in GitHub Copilot. Two are command injections and the other is a Time-of-check time-of-use (toctou) race condition, but both could end up in code execution on affected systems.

Patches for Elevation of Privilege (EoP) bugs make up nearly 50% of this release, but most simply lead to local attackers executing their code at SYSTEM-level privileges or administrative privileges. There are only two of note. The first is a command injection bug in GitHub Copilot that leads to executing code at the level of the targeted application. The second is a bug in a kernel that leads to SYSTEM but could also be used for a sandbox escape.

There’s a unusually high number of spoofing bugs in this month’s release, and the ones for Outlook are the most troubling. First, the Preview Pane is an attack vector. Secondly, the bugs could be used to relay NTLM credentials via just an email, which could result in credential disclosure. And you’ll need multiple patches to fully address these bugs. At least they can be applied in any order.  There’s a UI misrepresentation bug in Exchange Server that could allow an attacker to either view some sensitive information or “make changes to disclosed information”. At what point does data become disclosed? That odd phrasing makes me think they are using AI to right some of their descriptions. The phrasing also appears in the patch for NTLM. That bug is triggered by opening a specially crafted Office doc, and while they explicitly say it could be used to relay NTLM creds, it sure seems that way. The patch for .NET and Visual Studio fixes a bug that allows attackers to bypass header validation, resulting in the service accepting a message it should reject. Finally, the bug in Azure HDInsight is really just a cross-site scripting (XSS) bug. The caveat here is that you need to restart Ambari server in both of the head nodes to have this fix updated. There is also an XSS in Azure Devops Server, but at least it is labelled as such.

There are a couple of additional security feature bypass bugs to discuss. The first is in Hyper-V and bypasses the Virtualization-based Security feature. The other is in GitHub Copilot and Visual Studio Code. It’s another command injection, but this one can be used to bypass authentication. Neat.

Looking at the remaining info disclosure bugs getting patched this month, most simply result in info leaks consisting of unspecified memory contents or memory addresses. The exception is the bug in Azure IoT Explorer. This bug could be used to view the contents of the target user’s local file system.

We end this month’s release with two DoS bugs: one in LDAP and one in GDI+. Neither descriptions from Microsoft provide any usable information.

No new advisories are being released this month.

Looking Ahead

I plan on being back home for the March release but wherever I’m at, you can rest assured that March 10, I’ll be here to provide my assessment of the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Adobe Patches for April 2026

For April, Adobe released 12 bulletins addressing 61 unique CVEs in Adobe Acrobat Reader, InDesign, InCopy, FrameMaker, Connect, ColdFusion, Bridge, Photoshop, Illustrator, Experience Manager Screens, and the Adobe DNG SDK. Three of the Cold Fusion bugs came through the TrendAI ZDI program. For this month, I’m introducing an Adobe table as well. I’d love to get your feedback on whether this is helpful.

Obviously, the active attack in Reader is the highest priority for this month, but don’t ignore the second bunch of Reader patches. Cold Fusion also gets a deployment priority of 1, so if you’re still running that platform, make sure you get the update. Otherwise, the FrameMaker and Connect patches fix 11 and nine bugs, respectively. InDesign and Experience Manager Screens also have nine CVEs addressed.

Outside of the Reader bug, none of the other bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. One of the Reader bugs and Cold Fusion have a deployment priority of one, the other Reader bug has a priority of two, while all of the other updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for April 2026

This month, Microsoft released a monstrous 163 new CVEs in Windows and Windows components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, .NET and Visual Studio, SQL Server, Hyper-V Server, BitLocker, and the Windows Wallet Service. Counting the third-party and a huge Chromium release, it brings the total number of CVEs to a staggering 247 updates. Six of these bugs were reported through the TrendAI ZDI program. Eight of these bugs are rated Critical, two are rated as Moderate, and the rest are rated Important in severity.

By my count, this is the second-largest monthly release in Microsoft’s history. There are many things we could speculate on to justify the size, but if Microsoft is like the other programs out there (including ours), they are likely seeing a rise in submissions found by AI tools. For us, our incoming rate has essentially tripled, making triage a challenge, to say the least. Whatever the reason, we have a lot of bugs to deal with this month. I should also point out that the Pwn2Own Berlin occurs next month, and it’s typical for vendors to patch as much as they can before the event.

There is one Microsoft bug listed as under active attack at the time of release, and one other that’s publicly known. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerability being exploited in the wild:

-    CVE-2026-32201 - Microsoft SharePoint Server Spoofing Vulnerability
Microsoft doesn’t provide a lot of information about this bug, but Spoofing bugs in SharePoint often manifest as cross-site scripting (XSS) bugs. They do note that attackers could view information or make changes to disclosed information. As always, they don’t provide any information on how widespread these attacks are, but I wouldn’t wait to test and deploy this fix – especially if you have internet-connected SharePoint servers.

-    CVE-2026-33825 - Microsoft Defender Elevation of Privilege Vulnerability
This bug is listed as publicly known, and this time, we know exactly where it was disclosed. There have been some questions about how exploitable this bug may be, but it does look like it’s a real problem – just with some reliability issues in its current state. I won’t add on to the commentary from the researcher about working with Microsoft. I’m just glad they are offering a fix for the vulnerability. If you rely on Defender, test and deploy this one quickly.

-   CVE-2026-33827 - Windows TCP/IP Remote Code Execution Vulnerability
This vulnerability allows remote, unauthenticated attackers to exploit code on affected systems without user interaction. That adds up to a wormable bug – at least on systems with IPv6 and IPSec enabled. It is a race condition, which sets exploitability to High on the CVSS scale, but we see race conditions exploited at Pwn2Own all the time, so don’t rely on that obstacle. If you’re running IPv6, I would test and deploy this fix quickly before public exploits become available.

-    CVE-2026-33824 - Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability
Speaking of wormable bugs, here’s our second one this month. By the title, we can tell that systems with IKE enabled are affected, but that leaves plenty of targets for attackers. Microsoft also notes a significant mitigation for this bug. Blocking UDP ports 500 and 4500 at the perimeter prevents external attackers from reaching the affected service. However, insiders could still target this for lateral movement within an enterprise. For enterprises using IKE, get this fix tested and deployed with haste.

Here’s the full list of CVEs released by Microsoft for April 2026:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the other Critical-rated bugs in this month’s release, there are three Office-related bugs where the Preview Pane is once again listed as an exploit vector. I would still like to have a full-proof way of disabling the Preview Pane, but I don’t see that as an option. There’s a bug in the RDP client, but that involves connecting to a malicious RDP server. The bug in Active Directory requires authentication and a network adjacent attacker. The final Critical-rated bug is an interesting DoS in .NET Framework. An unauthenticated attacker could deny service over a network – presumably crippling any affected app made in .NET. You rarely see Critical-rated DoS bugs, but this one deserves the moniker.

Moving on to the other code execution bugs, you have quite a few open-and-own bugs in Office components, most notably Excel, where the Preview Pane is not an attack vector. The bug in SQL Server requires authentication, and as usual, additional steps are needed to ensure you have the correct update to remediate this vulnerability. The two bugs in Hyper-V almost reads like a privilege escalation since it allows unauthorized attackers to execute code locally. That’s the same for the bugs in the Windows Snipping Tool and the UPnP Device host.

More than half of this release addresses Elevation of Privilege (EoP) bugs. However, most simply lead to local attackers executing their code at SYSTEM-level privileges or administrative privileges, so there’s not much to add without further technical details about the bugs themselves. The bugs in SQL Server could allow an attacker to gain SQL sysadmin privileges. One of the kernel bugs simply states an attacker could “elevate privileges locally”. How obtuse. That’s similar for the bug in afd.sys and Desktop Windows Manager, but Microsoft also states that these bugs could crash an affected system. There are several bugs that result in a sandbox escape, including Windows Push Notifications, AFD for Winsock, Management Services, and User Interface Core. Of these, CVE-2026-26167 (Push Notifications) is the most notable — it's the only one with low attack complexity, meaning no race condition needed. The rest all require winning a race condition (AC:H). The bugs in UPnP are interesting as they allow attackers to gain access to a limited set of administrator-protected objects. Not a full escalation but definitely getting access to resources they shouldn’t. The vulnerability in the Brokering File System allows attackers to gain the level of the logged on user, so don’t do your normal activities as a user with admin privileges. The bug in Azure Monitor Agent leads to root-level access.

There are a dozen different security features bypass bugs in the April release. Some of these are obvious by the title alone. For example, the bugs in Windows Hello bypass safety features within the Hello app itself. The bug in the Biometric Service allows attackers to bypass biometric protections. The vulns in BitLocker and Secure Boot bypass protections in those components. The bug in Power Apps allows attackers to bypass a security warning dialog and trick targets into triggering an external protocol call that performs unintended actions on the user’s device. The bug in Windows Shell allows attackers to bypass Mark of the Web (MotW) protections. The bug in PowerShell could almost be described as a code execution bug as exploiting it bypasses dynamic-expression security checks, which could result in code execution. The vulnerability in the Windows Recovery Environment allows local attackers to bypass BitLocker device encryption. Finally, the bug in Virtualization‑Based Security (VBS) is the most interesting of the bunch – and not just because VBS is a (relatively) new feature. The problem allows attackers to manipulate allow a compromised Windows kernel to modify memory belonging to the secure kernel, breaking the intended isolation guarantees provided by VBS. Somewhat of a sandbox escape, but this time, you’re escaping from Virtual Trust Level 0 (VTL0) to Virtual Trust Level 1 (VTL1). Neat.

Moving on to the Information Disclosure bugs fixed this month, we have 20 different CVEs. Fortunately, most of these simply result in info leaks consisting of unspecified memory contents or memory addresses. While useful in crafting exploits, they aren’t exactly exciting on their own. There are also several bugs that disclose addresses from an object a contained in a sandboxed execution environment. This includes bugs in the Print Spooler, Package Catalog, and Web Account Manager. The bug in Dynamics 365 discloses the ever ineffable “sensitive information”. There are three different info disclosure bugs in UPnP. Two allow an attacker to read from the file system, while the third discloses anything available to the LOCAL SERVICE account. The final info disclosure bug resides in Copilot and Visual Studio and allows attackers to disclose the contents of the Model Context Protocol (MCP) when using Copilot. There are those who think MCP is dead (thanks to agentic AI agents), but if you’re using a custom MCP, I doubt you would want it leaked.

The April release contains just a handful of Spoofing bugs. Some, like the bugs in .NET, Active Directory, and Windows Shell, just say that they allow spoofing over a network. Others, like the bug in Windows Snipping Tool, say similar but also note that it could be used to relay NTLMv2 hashes. The patch for RDP notes that there are new warning dialogs coming this month. The bug in the Windows Admin Center would allow an attacker to interact with other tenant’s applications and content. Finally, the spoofing bug in SharePoint is another XSS issue.

There are eight DoS bugs in the April release, but as always, Microsoft provides no actionable information about the vulnerabilities. Microsoft does offer a mitigation for the http.sys bug that can be applied while you test and deploy the patch, but I would rely on the patch rather than the mitigation. Another exception is the bug for Connected User Experiences and Telemetry Service, which allows attackers to deny service locally rather than over the network.

The final(!) bug in the April release is a Tampering bug in WSUS that reads like a DoS. According to Microsoft, “An attacker can send specially crafted packets which could affect availability of the service and result in Denial of Service (DoS).” But sure – let’s call it Tampering.

No new advisories are being released this month.

Looking Ahead

I will be in Berlin for the next Patch Tuesday, which will be May 12, and I’ll provide my full thoughts then on what will hopefully be a smaller release than this one. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Willkommen zurück, meine Damen und Herren, zu unserem zweiten Wettbewerb in Berlin! That’s correct (if Google translate didn’t steer me wrong). After our inaugural competition last year, Pwn2Own returns to Berlin and OffensiveCon. Outside of our shipping troubles, we had an amazing time and can’t wait to get back.

Last year, we added Artificial Intelligence as a category with great results. This year, we’re expanding this and splitting it into multiple different categories: AI Databases, Coding Agents, Local Inferences, and a separate category for NVIDIA products. In last year’s contest, NVIDIA targets had wins, losses, and collisions, so it will be interesting to see how they fare this year. The folks from AWS wanted to get into the fray as well, so they stepped up to co-sponsor this year’s event, which allows us to increase the reward for bugs in Firecracker. Of course, we have all of the returning categories as well, including web browsers, containers, servers, virtualization, and operating systems. There’s more than $1,000,000 in cash and prizes available for contestants. Last year, we awarded $1,078,750 for 28 unique 0-days over the three-day event. We’ll see if we can eclipse those numbers in 2026.

The contest begins on May 14, but registration closes on May 7, so don’t delay in getting those submissions in. We’re hoping for maximum participation, so set aside your vibe coding and show us what you can really do. We’re looking forward to some cutting-edge exploitation on display. For 2026, we have a total of 31 targets across 10 categories. Here is a full list of the categories for this year’s event:  

-- Virtualization
-- Web Browser
-- Enterprise Applications
-- Servers
-- Local Escalation of Privilege
-- Containers
-- AI Database
-- Coding Agents
-- Local Inference
-- NVIDIA

Of course, no Pwn2Own competition would be complete without us crowning a Master of Pwn (Meister von Pwn?). Since the order of the contest is decided by a random draw, contestants with an unlucky draw could still demonstrate fantastic research but receive less money since subsequent rounds go down in value. However, the points awarded for each unique, successful entry do not go down. Someone could have a bad draw and still accumulate the most points. The person or team with the most points at the end of the contest will be crowned Master of Pwn, receive 65,000 ZDI reward points (enough for Platinum status), a killer trophy, and a pretty snazzy jacket to boot.

Let's look at the details of the rules for this year's event.

Virtualization Category

Some of the highlights for each contest can be found in the Virtualization Category, and we’re thrilled to see what this year’s event could bring with it. As usual, VMware is the main highlight of this category as we’ll have VMware ESXi return with an award of $150,000. Last year produced the first ESXi exploits in Pwn2Own history, so it will be interesting to see if we get more. Microsoft also returns as a target and leads the virtualization category with a $250,000 award for a successful Hyper-V Client guest-to-host escalation. Kernel-based Virtual Machine (KVM) is our final target in this category with a prize of $50,000.

There’s an add-on bonus in this category as well. If a contestant can escape the guest OS, then gain arbitrary code execution on the virtualization target and obtain arbitrary code execution in the guest operating system on a separate virtual machine managed by the same targeted virtualization target, they’ll earn another $50,000. That could push the payout on a ESXi bug to $200,000. This bonus is for KVM and ESXi only. Here’s a detailed look at the targets and available payouts in the Virtualization category:

Back to top

Web Browser Category

While browsers are the “traditional” Pwn2Own target, we’re continuously tweaking the targets in this category to ensure they remain relevant. We re-introduced renderer-only exploits a couple of years ago, and this year, we’ve increased the award to $75,000. In fact, we’ve increased the awards across the board for this category. Here’s a detailed look at the targets and available payouts:

Back to top

Enterprise Applications Category

Enterprise applications return as targets with Adobe Reader and various Office components on the target list once again. Attempts in this category must be launched from the target under test. For example, launching the target under test from the command line is not allowed. Prizes in this category run from $50,000 for a Reader exploit with a sandbox escape or a Reader exploit with a kernel privilege escalation, and $150,000 for an Office 365 application. Word, Excel, and PowerPoint are all valid targets. Microsoft Office-based targets will have Protected View enabled where applicable. Adobe Reader will have Protected Mode enabled where applicable.

This year, we’re adding a bonus for Copilot data exfiltration and Copilot action execution. Microsoft just patched a bug like this in Excel, so we know they are out there. If you’re able to exploit Copilot in addition to a Microsoft application, you’ll earn an additional $50,000. There are quite a few rules and scenarios around this add-on, so be sure to read the rules carefully and contact us with questions. Here’s a detailed view of the targets and payouts in the Enterprise Application category:

Back to top

The Server Category

The Server Category for 2026 focuses solely on the server components we’re most interested in. These servers are often targeted by everyone from ransomware crews to nation/state actors, so we know there are exploits out there for them. The only question is whether we’ll see any of the competitors bring one of those exploits to Pwn2Own. Last year, the bugs demonstrated in SharePoint ended up being exploited in the wild, so we know people are looking for these with great interest. Microsoft Exchange has been a popular target for some time, and it returns as a target this year as well, with a payout of $200,000. This category is rounded out by Microsoft Windows RDP/RDS, which also has a payout of $200,000. Here’s a detailed look at the targets and payouts in the Server category:

Back to top

Local Escalation of Privilege Category

This category is a classic for Pwn2Own and focuses on attacks that originate from a standard user and result in executing code as a high-privileged user. A successful entry in this category must leverage a kernel vulnerability to escalate privileges. Red Hat Enterprise Linux for Workstations returns as our Linux-based target, while Apple macOS, and Microsoft Windows 11 return as targets in this category. Prior exploits in this category have won Pwnie awards, so they’re always interesting to see. Here’s a detailed look at the targets and payouts in this category:

Back to top

The Container Category

We’re excited to have this category return for its third season, and we’re hopeful that even more contestants will target one of these container targets. For an attempt to be ruled a success against these three, the exploit must be launched from within the guest container/microVM and execute arbitrary code on the host operating system. Again, with help from AWS, Firecracker returns as a target with a prize of $100,000. Here are the targets and payouts for this category:

Back to top

AI Database Category

In the past, AI Hackathons have focused on using AI to develop vulnerabilities or other offensive frameworks. We’re opening up the models and various components themselves for exploitation. The first AI sub-category focuses on databases. An attempt in this category must be launched from the contestant’s laptop. Here’s a look at the targets and awards in the AI Database category:

Back to top

The Coding Agent Category

Let’s face it. At some point or another, we’ve probably all vibe coded something. There’s no shame in that, but how secure are the tools we use for vibe coding? Well, let’s take the most popular choices and find out. A successful entry must interact with a contestant-controlled resource (e.g. web page, repository, media file) to exploit a vulnerability within the coding agent. The attack vector of the entry must be a common coding agent use case. There are few things out of scope here as well. UI spoofing or misrepresentation unrelated to permission prompts, model jailbreaks or prompt outputs that do not cross security boundaries, and vulnerabilities that require unsafe or permission-less modes are just a few of the things not allowed. As this is a new category, please read the rules carefully to ensure your entry qualifies. Here’s a look at the targets and awards in the AI Coding Agent category:

Back to top

The Local Inference Category

We couldn’t leave local inference and LLMs out of Pwn2Own. These products claim to provide enhanced data privacy, zero-cost inference, lower latency, and fully offline functionality. We’ll see how the security stacks up. An attempt in this category must be launched from the contestant’s laptop within the contest network. Here are the targets and payouts for the Local Inference category:

Back to top

The NVIDIA Category

Our last AI sub-category focuses solely on NVIDIA products. For network accessible targets, an attempt must be launched from the contestant's laptop within the contest network. For NV Container Toolkit, the attempt must be launched from within a crafted container image and execute arbitrary code on the host operating system. For Megatron Bridge, entries that leverage vulnerabilities pertaining to pickle deserialization or that leverage a vulnerability when “trust_remote_code=true” are out of scope. Here are the targets and payouts for the NVIDIA category:

Back to top

Conclusion

The complete rules for Pwn2Own Berlin 2026 are found here. As always, we highly encourage entrants to read the rules thoroughly if they choose to participate. If you are thinking about participating but have specific configuration or rule-related questions, email us. Questions asked over X (nee Twitter), BlueSky, or other means will not be answered. Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at pwn2own@trendmicro.com to begin the registration process. Registration for onsite participation closes at 5 p.m. Central European Time on May 7, 2026.

Be sure to stay tuned to this blog and follow us on Twitter, Mastodon, LinkedIn, or Bluesky for the latest information and updates about the contest. We look forward to seeing everyone in Germany, and we hope to see some of the best in the world show what they can do – vibe coded or not.

With special thanks to our Pwn2Own Berlin 2026 partners AWS, for providing their expertise and technology.

© 2026 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, ZERO DAY INITIATIVE, TrendAI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

Es gibt neue Details zum weitreichenden Sicherheitsvorfall rund um OpenAI und Hugging Face, worüber wir an dieser Stelle bereits berichtet haben. Wie ZDFheute unter Berufung auf Reuters nun verkündet, kam es bei insgesamt zwei KI-Modellen – neben dem aktuellen GPT-5.6 Sol einem weiteren Vorabmodell – über mehrere Tage zu einem vollständigen Kontrollverlust bei OpenAI. Hugging […]

Der Beitrag OpenAI: KI-Cybervorfall ruft FBI und Sicherheitsforscher auf den Plan erschien zuerst auf Dr. Windows.

Maximize app performance and ROI with the R8 Configuration Analyzer

A premium experience is only as good as its foundation, and a performant foundation is what allows your app to scale across the Android ecosystem. This is especially true with the release of Android 17, which introduces conservative, device RAM-based app memory limits to target extreme memory leaks and outliers before they cause system-wide instability. To stay below these new system thresholds and prevent your app from being terminated, having a lean footprint is no longer optional: it’s a critical requirement.

This year, we’re making it easier to build highly optimized, fast apps by introducing the R8 Configuration Analyzer in Android Studio. R8 is your most powerful tool for improving app performance, but its effectiveness is often limited by overly broad "keep rules" that prevent the compiler from stripping away unused code. The new Configuration Analyzer provides optimization, obfuscation, and shrinking scores, allowing you to identify specific rules that are preventing the benefits of R8 optimization.

By optimizing their R8 configurations, developers at Monzo achieved a 30% improvement in cold starts and a 35% reduction in ANRs. Smaller, faster code isn't just about efficiency; it's about ensuring your app has the memory headroom to deliver delight on every form factor, from the phone to the car.

Extend your reach with a unified approach to Widgets on Phones, Watches and Cars

User interaction is shifting toward quick, glanceable moments—short bursts of information that keep users connected without needing to open the full app. To help you increase the reach of your app content, we are unifying the development experience across the Android ecosystem with Jetpack Glance. By using a consistent, Compose-based model, you can elevate the content most important to your users straight to the phone’s home screen, Wear Widgets (previously Tiles!), and cars with a familiar workflow.

In order to help users engage with your content and features, even outside your app, we are making widgets more expressive and adaptive with RemoteCompose. On Wear OS, RemoteCompose allows you to use the Compose tools you’re already comfortable with to define UI logic that renders natively on remote surfaces, ensuring that your glanceable experiences remain highly performant and responsive even on resource-constrained hardware. On mobile and cars, RemoteCompose is used as a new framework giving Widgets new expressive capabilities.

You can use Jetpack Glance (together with RemoteCompose on Wear) to deliver a cohesive user journey. Whether it’s viewing flight status on the car dashboard, checking a gate change on a watch, or managing a boarding pass from a phone widget, this shared approach maximizes your app’s presence while keeping your development effort focused and efficient.

For more details, check out the premium Android experience YouTube playlist.

Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months.

Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity.

Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works.

Let's dive deeper into Android 17.

An intelligence system

With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state.

The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments.

/**
 * A note app's [AppFunction]s.
 */
class NoteFunctions(
    private val noteRepository: NoteRepository
) {
    /**
     * Adds a new note to the app.
     *
     * @param appFunctionContext The execution context.
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }
}

We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging.

The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production.

Adaptive-first

Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks, the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard.

No resizability/orientation restrictions on large screens

To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively.

Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP

Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps:

• App Bubbles: Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow.
• The Bubble Bar: On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles.
• Desktop interactive PiP: In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows.

App Bubbles and Bubble Bar in action

Activity recreation updates

To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE).
Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute.

Continue On

Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed.

Handoff Suggestion on a Tablet

class MyHandoffActivity : Activity() {

    ...

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Do stuff
    ...
    // Enable handoff
    setHandoffEnabled(true, null)
  }

  // Override and implement onHandoffActivityDataRequested
  override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
    // Create and return handoff data
  }
}

Go adaptive-first with Jetpack Compose

To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill. This AI-powered developer workflow helps you implement the best adaptive practices:

• Adaptive navigation: Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library.
• Multi-pane layouts: Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions.
• FlexBox & Grid APIs: Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully.
• Advanced non-touch input: Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode.
• Dynamic window states: Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions.

Android is Compose-first

Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features.

TIP
Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code.

Performance & efficiency

App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas.

App memory limits

Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. 

Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements:

• R8 Optimizer: The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8.
  

• LeakCanary in Android Studio Panda: The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code.
• ApplicationExitInfo: If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap".
• On-Device Anomaly Detection: Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached.

val profilingManager = applicationContext
   .getSystemService(ProfilingManager::class.java)

val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

And, we're working to surface more in-field memory metrics to you within Google Play Console.

Generational garbage collection

Android 17 introduces more frequent, less resource-intensive young-generation collections to ART's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates.

Lock-Free MessageQueue

For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods.  The peekWhen and poll APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals.

Static final fields now truly final

Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application.

Custom notification view restrictions

To reduce memory usage we are further restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher.

Privacy & Security

Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences.

Privacy-preserving choices

Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects:

• System-Level Contact Picker: Utilizing ACTION_PICK_CONTACTS, apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad READ_CONTACTS permission. It also fully supports work/personal profile separation.
• Customizable Photo Picker aspect ratio: UsingPhotoPickerUiCustomizationParams, you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps.
• System-rendered Location Button: A new system-rendered location button that you can embed in your app grants precise location access for the current session only.
• EyeDropper API: A new system-level API, ACTION_OPEN_EYE_DROPPER, allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
   if (result.resultCode == Activity.RESULT_OK) {
       val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
       // Use the picked color in your app
   }
}
fun launchColorPicker() {
   val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
   eyeDropperLauncher.launch(intent)
}

Picking a color from anywhere on the screen with the system EyeDropper

Local network access

Apps targeting Android 17 now either require the ACCESS_LOCAL_NETWORK runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again.

SMS OTP protection

Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours:

• WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch).
• Standard SMS OTP: Delayed for all apps targeting SDK 37+.
• Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs.

Post-Quantum Cryptography (PQC)

Android 17 is ready for the next generation of cryptographic security:

• Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs.
• Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery.

Safer native dynamic code loading 

Smarter password protection for physical inputs

With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default.

Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer).

These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields.

Media and camera features that empower creators and delight users

Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers.

• Eclipsa Video: HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content.
• RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors.
• Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features.
• Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata.
• Versatile Video Coding (H.266): Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor.
• Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera.
• Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video.

Better support for hearing aids

• Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices.
• Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps.

CameraX and Media3

CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences.

We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX.

Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices.

Get your apps, libraries, tools, and game engines ready!

If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17.

Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following:

• Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens.
• Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.
• Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)
• Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.
• Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance.
• NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI.

Get started with Android 17

Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air.

Getting the Android 17 beta on partner devices

Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi.

For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail. Once you’re set up, here are some of the things you should do:

Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or Android Emulator running Android 17 and extensively test it.

Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward.

For complete information on Android 17 please visit the Android 17 developer site.

Note: This joint Cybersecurity Advisory is being published as an addition to the Cybersecurity and Infrastructure Security Agency (CISA) May 6, 2025, joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology and European Cybercrime Centre’s (EC3) Operation Eastwood, in which CISA, Federal Bureau of Investigation (FBI), Department of Energy (DOE), Environmental Protection Agency (EPA), and EC3 shared information about cyber incidents affecting the operational technology (OT) and industrial control systems (ICS) of critical infrastructure entities in the United States and globally.

FBI, CISA, National Security Agency (NSA), and the following partners—hereafter referred to as “the authoring organizations”—are releasing this joint advisory on the targeting of critical infrastructure by pro-Russia hacktivists:

• U.S. Department of Energy (DOE)
• U.S. Environmental Protection Agency (EPA)
• U.S. Department of Defense Cyber Crime Center (DC3)
• Europol European Cybercrime Centre (EC3)
• EUROJUST – European Union Agency for Criminal Justice Cooperation
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Canadian Centre for Cyber Security (Cyber Centre)
• Canadian Security Intelligence Service (CSIS)
• Czech Republic Military Intelligence (VZ)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)
• Czech Republic National Centre Against Terrorism, Extremism, and Cyber Crime (NCTEKK)
• French National Cybercrime Unit – Gendarmerie Nationale (UNC)
• French National Jurisdiction for the Fight Against Organized Crime (JUNALCO)
• German Federal Office for Information Security (BSI)
• Italian State Police (PS)
• Latvian State Police (VP)
• Lithuanian Criminal Police Bureau (LKPB)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• Romanian National Police (PR)
• Spanish Civil Guard (GC)
• Spanish National Police (CNP)
• Swedish Polisen (SC3)
• United Kingdom National Cyber Security Centre (NCSC-UK)

The authoring organizations assess pro-Russia hacktivist groups are conducting less sophisticated, lower-impact attacks against critical infrastructure entities, compared to advanced persistent threat (APT) groups. These attacks use minimally secured, internet-facing virtual network computing (VNC) connections to infiltrate (or gain access to) OT control devices within critical infrastructure systems. Pro-Russia hacktivist groups—Cyber Army of Russia Reborn (CARR), Z-Pentest, NoName057(16), Sector16, and affiliated groups—are capitalizing on the widespread prevalence of accessible VNC devices to execute attacks against critical infrastructure entities, resulting in varying degrees of impact, including physical damage. Targeted sectors include Water and Wastewater Systems, Food and Agriculture, and Energy.

The authoring organizations encourage critical infrastructure organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of pro-Russia hacktivist-related incidents. For additional information on Russian state-sponsored malicious cyber activity, see CISA’s Russia Threat Overview and Advisories webpage.

Download the PDF version of this report:

Background and Development of Pro-Russia Hacktivist Groups

Over the past several years, the authoring organizations have observed pro-Russia hacktivist groups conducting cyber operations against numerous organizations and critical infrastructure sectors worldwide. The escalation of the Russia-Ukraine conflict in 2022 significantly increased the number of these pro-Russia groups. Consisting of individuals who support Russia’s agenda but lack direct governmental ties, most of these groups target Ukrainian and allied infrastructure. However, among the increasing number of groups, some appear to have associations with the Russian state through direct or indirect support.

Cyber Army of Russia Reborn

The authoring organizations assess that the Russian General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455—tracked in the cybersecurity community under several names (see Appendix B: Additional Designators Used for Cited Groups)—is likely responsible for supporting the creation of CARR —also known as “The People’s Cyber Army of Russia”—in late February or early March of 2022. Actors suspected to be from GRU unit 74455 likely funded the tools CARR threat actors used to conduct distributed denial-of-service (DDoS) attacks through at least September 2024.

In April 2022, the group began using a new Telegram channel featuring the name “CyberArmyofRussia_Reborn” to organize and plan group actions. The channel creators recruited actors to use CARR as an unattributable platform for conducting cyber activities beneath the level of an APT, aimed at deterring anti-Russia rhetoric. CARR threat actors presented themselves as a group of pro-Russia hacktivists supporting Russia’s stance on the Ukrainian conflict, and they soon began claiming responsibility for DDoS attacks against the U.S. and Europe for supporting Ukraine.

CARR documented these actions through embellished images and videos shared on their social media channels, promoting Russian ideology, disseminating talking points, and publicizing leaked information from hacks attributed to Russian state threat actors.

In late 2023, CARR expanded their operations to include attacks on industrial control systems (ICS), claiming an intrusion against a European wastewater treatment facility in October 2023. In November 2023, CARR targeted human-machine interface (HMI) devices, claiming intrusions at two U.S. dairy farms.

The authoring organizations assess that by late September 2024, CARR channel administrators became dissatisfied with the level of support and funding provided by the GRU. This dissatisfaction led CARR administrators and an administrator from another hacktivist group, NoName057(16), to create the Z-Pentest group, employing the same tactics, techniques, and procedures (TTPs) as CARR but separate from GRU involvement.

NoName057(16)

The authoring organizations assess that the Center for the Study and Network Monitoring of the Youth Environment (CISM), established on behalf of the Kremlin, created NoName057(16) as a covert project within the organization. Senior executives and employees within CISM developed and customized the NoName057(16) proprietary DDoS tool DDoSia, paid for the group’s network infrastructure, served as administrators on NoName057(16) Telegram channels, and selected DDoS targets.

Active since March 2022, NoName057(16) has conducted frequent DDoS attacks against government and private sector entities in North Atlantic Treaty Organization (NATO) member states and other European countries perceived as hostile to Russian geopolitical interests. The group operates primarily through Telegram channels and used GitHub, alongside various websites and repositories, to host DDoSia and share materials and TTPs with their followers. 

In 2024, NoName057(16) began collaborating closely with other pro-Russia hacktivist groups, operating a joint chat with CARR by mid-2024. In July 2024, NoName057(16) jointly claimed responsibility with CARR for an alleged intrusion against OT assets in the U.S. The high degree of cooperation with CARR likely contributed to the formation of Z-Pentest, which is composed of actors and administrators from both teams, in September 2024.

Z-Pentest

Established in September 2024, Z-Pentest is composed of members from CARR and NoName057(16). The group specializes in OT intrusion operations targeting globally dispersed critical infrastructure entities. Additionally, the group uses “hack and leak” operations and defacement attacks to draw attention to their pro-Russia messaging. Unlike other pro-Russia hacktivist groups, Z-Pentest largely avoids DDoS activities, claiming OT intrusions as attempts to garner more attention from the media.

Shortly after Z-Pentest’s inception, the group announced alliances with CARR and NoName057(16), possibly to leverage the other groups’ subscribers to grow the new channel. In March 2025, Z-Pentest posted evidence claiming OT device intrusions to their channel using a NoName057(16) cyberattack campaign hashtag. Similarly, in April 2025, Z-Pentest shared a video purporting defacement of an HMI by changing system names to NoName057(16) and CARR references. Z-Pentest continues to create new alliances with other groups, like Sector16, to continue growing their subscriber base and incidentally propagate TTPs with new partners.

Sector16

Formed in January 2025, Sector16 is a novice pro-Russia hacktivist group that emerged through collaboration with Z-Pentest. Sector16 actively maintains an online presence, including a public Telegram channel where they share videos, statements, and claims of compromising U.S. energy infrastructure. These communications often align with pro-Russia narratives and reflect their self-proclaimed support for Russian geopolitical objectives.

Members of Sector16 may have received indirect support from the Russian government in exchange for conducting specific cyber operations that further Russian strategic goals. This aligns with broader Russian cyber strategies that involve leveraging non-state threat actors for certain cyber activities, adding a layer of deniability.

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 18. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

TTP Overview

Pro-Russia hacktivist groups employ easily disseminated and replicated TTPs across various entities, increasing the likelihood of widespread adoption and escalating the frequency of intrusions. These groups have limited capabilities, frequently misunderstanding the processes they aim to disrupt. Their apparent low level of technical knowledge results in haphazard attacks where actors intend to cause physical damage but cannot accurately anticipate actual impact. Despite these limitations, the authoring organizations have observed these groups willfully cause actual harm to vulnerable critical infrastructure.

Pro-Russia hacktivist groups use the TTPs in this Cybersecurity Advisory to target virtual network computing (VNC)-connected HMI devices. These groups are primarily seeking notoriety with their actions. While they have caused damage in some instances, they regularly make false or exaggerated claims about their attacks on critical infrastructure to garner more attention. They frequently misrepresent their capabilities and the impacts of their actions, portraying minor incursions as significant breaches, but such incursions can still lead to lost time and resources for operators remediating systems.

Additionally, pro-Russia hacktivists use an opportunistic targeting methodology. They leverage superficial criteria, such as victim availability and existing vulnerabilities, rather than focusing on strategically significant entities. Their lack of strategic focus can lead to a broad array of targets, ranging from water treatment facilities to oil well systems. Pro-Russia hacktivists have demonstrated a pattern of frequently taking advantage of the widespread availability of vulnerable VNC connections. While system owners typically use VNC connections for legitimate remote system access functions, threat actors can maliciously use these connections to broadly target numerous platforms and services. Consequently, these groups can indiscriminately compromise critical infrastructure entities, including those in the Water and Wastewater, Food and Agriculture, and Energy Sectors.

Pro-Russia hacktivist groups have successfully targeted supervisory control and data acquisition (SCADA) networks using basic methods, and in some cases, performed simultaneous DDoS attacks against targeted networks to facilitate SCADA intrusions. As recently as April 2025, threat actors used the following unsophisticated TTPs to access networks and conduct SCADA intrusions:

• Scan for vulnerable devices on the internet [T0883] with open VNC ports [T1595.002].
• Initiate temporary virtual private server (VPS) [T1583.003] to execute password brute force software.
• Use VNC software to access hosts [T1021.005].
• Confirm connection to the vulnerable device [T0886].
• Brute force the password, if required [T1110.003].
• Gain access to HMI devices [T0883], typically with default [T0812], weak, or no passwords [T0859].
• Log the confirmed vulnerable device IP address, port, and password.
• Using the HMI graphical interface [T0823], capture screen recordings or intermittent screenshots while conducting the following actions, intending to affect productivity and cause additional costs [T0828]:
  • Modify usernames/passwords [T0892];
  • Modify parameters [T0836];
  • Modify device name [T0892];
  • Modify instrument settings [T0831];
  • Disable alarms [T0878];
  • Create loss of view (a technique that mandates local hands-on operator intervention) [T0829]; and/or
  • Device restart or shutdown [T0816].
• Disconnect from the device, ending the VNC connection.
• Research the compromised device company after the intrusion [T1591].

Propagation

To reach a wider audience, pro-Russia hacktivist groups work together, amplify each other’s posts, create additional groups to amplify their own posts, and likely share TTPs. For example, Z-Pentest jointly claimed intrusion of a U.S. system with Sector16. Sector16 later began posting additional intrusions for which the group claimed sole responsibility. It is likely that these and similar groups will continue to iterate and share these methods to disrupt critical infrastructure organizations.

Reconnaissance and Initial Access

The threat actors’ intrusion methodology is relatively unsophisticated, inexpensive to execute, and easy to replicate. These pro-Russia hacktivist groups abuse popular internet-scraping tools, such as Nmap or OPENVAS, to search for visible VNC services and use brute force password spraying tools to access devices via known default or otherwise weak credentials. Threat actors typically search for these services on the default port 5900 or other nearby ports (5901-5910). Their goal is to gain remote access to HMI devices connected to live control networks.

Once threat actors obtain access, they manipulate available settings from the graphical user interface (GUI) on the HMI devices, such as arbitrary physical parameter and setpoint changes, or conduct defacement activities. Because pro-Russia hacktivist groups seem to lack sector-specific expertise or cyber-physical engineering knowledge, they currently cannot reliably estimate the true impact of their actions. Regardless of outcome, pro-Russia hacktivist groups often post images and screen recordings to their social media platforms, boasting the compromises and exaggerating impacts to garner attention from their peers and the media.

Impact

While pro-Russia hacktivist groups currently demonstrate limited ability to consistently cause significant impact, there is a risk that their continued attacks will result in further harm or grievous physical consequences. Attacks have not yet caused injury; however, the attacks against occupied factories and community facilities demonstrate a lack of consideration for human safety.

Victim organizations reported that the most common operational impact caused by these threat actors is a temporary loss of view, necessitating manual intervention to manage processes. However, any modifications to programmatic and systematic procedures can result in damage or disruption, including substantial labor costs from hiring a programmable logic controller programmer to restore operations, costs associated with operational downtime, and potential costs for network remediation.

MITRE ATT&CK Tactics and Techniques

See Table 1 to Table 10 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Incident Response

If organizations find exposed systems with weak or default passwords, they should assume threat actors compromised the system and begin the following incident response protocols:

1. Determine which hosts were compromised and isolate them by quarantining or taking them offline.
2. Initiate threat hunting activities to scope the intrusion. Collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.
3. Reimage compromised hosts.
4. Provision new account credentials.
5. Report the compromise to CISA, FBI, and/or NSA. See the Contact Information section of this advisory.
6. Harden the network to prevent additional malicious activity. See the Mitigations section of this advisory for guidance.

Mitigations

OT Asset Owners and Operators

The authoring organizations recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture based on the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

• Reduce exposure of OT assets to the public-facing internet. When connected to the internet, OT devices are easy targets for malicious cyber threat actors. Many devices can be found by searching for open ports on public IP ranges with search engine tools to target victims with OT components [CPG 3.S].
  • Asset owners should use attack surface management services and web-based search platforms to scan the internet. This mitigation can help identify if there are VNC systems exposed within the IP ranges they own, especially for connections set up by third parties.
    Note: For more information on attack surface management, see CISA’s Internet Exposure Reduction Guidance, CISA’s Cyber Hygiene Services for U.S. critical infrastructure, and NSA’s Attack Surface Management for the U.S. Defense Industrial Base.
  • Implement network segmentation between IT and OT networks. Segmenting critical systems and introducing a demilitarized zone (DMZ) for passing control data to enterprise logistics reduces the potential impact of cyber threats and the risk of disruptions to essential OT operations [CPG 3.I].
  • Consider implementing a firewall and/or virtual private network if exposure to the internet is necessary for controlling access to devices.
    • Consider disabling public exposure by default and implementing time-limited remote access to reduce the amount of time systems are exposed.
    • Restrict and monitor both inbound and outbound traffic at OT perimeter firewalls. Configure OT perimeter firewalls to enforce a default-deny policy for all traffic. Asset owners should explicitly permit authorized destinations and protocols based on operational requirements.
    • Implement strict egress filtering to prevent unauthorized data exfiltration or command-and-control callbacks.
    • Regularly audit firewall rulesets and monitor outbound traffic patterns for anomalies indicative of threat actor activity, such as beaconing or unexpected protocol usage.
• Adopt mature asset management processes, including mapping data flows and access points. Generating a complete picture of both OT and IT assets provides visibility to operators and management, allowing organizations to monitor and assess deviations for criticality [CPG 2.A].
  • Keep remote access services updated with the latest version available and ensure all systems and software are up to date with patches and necessary security updates.
    • Keep VNC systems updated with the latest version available.
  • Refer to the joint Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators to help with reducing cybersecurity risk by identifying which assets within their environment should be secured and protected.
• Ensure OT assets use robust authentication procedures.
  • Many devices lack robust authentication and authorization. Devices with weak authentication are vulnerable targets to threat actors using credential theft techniques.
  • Implement MFA where possible. Where MFA is not feasible, use strong, unique passwords. Apply password standards for operator-accessible services on underlying OT assets, as well as network devices protecting those services. This is especially important for services that require internet accessibility [CPG 3.A] [CPG 3.B] [CPG 3.C] [CPG 3.F].
  • Establish an allowlist that permits only authorized device IP addresses and/or media access control addresses. The allowlist can be refined to operator working hours to further obstruct malicious threat actor activity; organizations are encouraged to establish monitoring and alerting for access attempts not meeting these criteria [CPG 3.E].
  • Disable any unused authentication methods, logic, or features, such as default authentication keys and default passwords. Block all unused high ephemeral ports and monitor for attempted connections using standard protocols on non-standard ports [CPG 3.R].
  • Authenticate all access to field controllers before authorizing access to, or modification of, a device’s state, logic, program, or filesystems.
• Enable control system security features that can separate and audit view and control functions. Limiting remotely accessible or default user accounts to “view-only” removes the potential for impact without exploiting a vulnerability [CPG 3.G].
• Implement and practice business recovery/disaster recovery plans. Plans should also take into consideration redundancy, fail-safe mechanisms, islanding capabilities, backup restoration, and manual operation.
  • Include scenarios that necessitate switching to manual operations. Maintaining the capability of an organization to revert to manual controls to quickly restore operations is vital in the immediate aftermath of a cyber incident [CPG 6.A].
  • Create backups of the engineering logic, configurations, and firmware of HMIs to enable fast recovery. Organizations should routinely test backups and standby systems to ensure safe manual operations in the event of an incident [CPG 3.O].
• Collect and monitor the traffic of OT assets and networking devices. This includes unusual logins or unexpected protocols communicating over the internet, and functions of ICS management protocols that change an asset’s operating mode or modify programs.
• Review configurations for setpoint ranges or tag values to stay within safe ranges and establish alerting for deviations.
• Take a proactive approach in the procurement process by following the guidance outlined in the joint guide Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.

OT Device Manufacturers

Although critical infrastructure organizations can take steps to mitigate risks, it is ultimately the responsibility of OT device manufacturers to build products that are secure by design. The authoring organizations urge device manufacturers to take ownership of the security outcomes of their customers in line with the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software.

• Eliminate default credentials and require strong passwords. The use of default credentials is a top weakness threat actors exploit to gain access to systems.
• Mandate MFA for privileged users. Changes to engineering logic or configurations are safety-impacting events in critical infrastructure. MFA should be available for safety critical components at no additional cost.
• Practice secure by default principles. OT components were initially designed without public internet connectivity in mind. When internet connection becomes necessary, implementing additional security measures is essential to safeguard these systems. Manufacturers should recognize insecure states and promptly inform users so they can make informed risk decisions.
  • Include logging at no additional charge. Change and access control logs allow operators to track safety-impacting events in their critical infrastructure. These logs should be available for no cost and use open standard logging formats.
• Publish Software Bill of Materials (SBOMs). Vulnerabilities in underlying software libraries can affect a wide range of devices. Without an SBOM, it is nearly impossible for a critical infrastructure system owner to measure and mitigate the impact of a vulnerability on their existing systems. See CISA’s SBOM webpage for more information.

Additionally, see CISA’s Secure by Design Alert on how software manufacturers can shield web management interfaces from malicious cyber activity. By using secure by design tactics, software manufacturers can make their product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing tiered security software and logs, monitoring, and making routine updates.

For more information on secure by design, see CISA’s Secure by Design webpage.

Validate Security Controls

In addition to applying mitigations, the authoring organizations recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK Matrix for Enterprise framework in this advisory. The authoring organizations recommend testing your existing security controls inventory to assess how it performs against the ATT&CK techniques described in this advisory.

To start:

1. Select an ATT&CK technique described in this advisory (see Table 1 to Table 10).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring organizations recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Resources

Entities requiring additional support for implementing any of the mitigations in this advisory should contact their regional CISA Cybersecurity Advisor for assistance. Key resources organizations should reference include:

• CISA, EPA, NSA, FBI, ASD’s ACSC, Cyber Centre, BSI, NCSC-NL, and NCSC-NZ’s Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators offers best practices to assist organizations in identifying and prioritizing which assets should be secured and protected.
• CISA, FBI, NSA, EPA, DOE, USDA, FDA, MS-ISAC, Cyber Centre, and NCSC-UK’s guidance on Defending OT Operations Against Ongoing Pro-Russia Hacktivist Activity that can help organizations protect OT systems from pro-Russia hacktivist activity.
• NSA and CISA’s guidance on Control System Defense: Know the Opponent helps organizations defend OT and ICS assets against malicious cyber activity.
• CISA and EPA’s resource page on Water and Wastewater Cybersecurity to help organizations reduce risks posed by malicious cyber actors targeting water and wastewater systems.
  • For additional guidance, see CISA, EPA, and FBI’s fact sheet on Top Cyber Actions for Securing Water Systems.
• The Food and Ag-ISAC’s best practices on Food and Ag Cybersecurity: A Guide for Small & Medium Enterprises provides recommendations to help mitigate against cyber threats.
• DOE and National Association of Regulatory Utility Commissioners Cybersecurity Baselines for Electric Distribution Systems and Distributed Energy (DER) webpage provides resources for state public utility commissions and utilities, as well as DER operators and aggregators to help mitigate cybersecurity risks.

Additional resources that apply to this advisory include:

• EPA’s Cybersecurity for the Water Sector resource page provides organizations with guidance on implementing basic cyber hygiene practices.
• CISA’s Cross-Sector Cybersecurity Performance Goals enables critical infrastructure organizations to reduce the likelihood and impact of known risks and adversary techniques.
• CISA’s Require Strong Passwords webpage supports small and medium-sized businesses mitigating against malicious cyber activity that targets weak passwords.
• CISA, NSA, FBI, EPA, TSA, and international partners’ guidance Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.
• DOE’s guidance on Cyber-Informed Engineering recommends considering cyber-enabled risks during the conception, design, and development phases when manufacturing physical systems.
• CISA’s Cyber Hygiene Services help enable critical infrastructure organizations to reduce their exposure to threats by taking a proactive approach to monitoring and mitigating attack vectors.
• CISA, NSA, FBI, and international partners’ guidance on Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software urges software manufacturers to provide customers with products that are safer and more secure.
  • See more information in these Secure by Design Alerts: How Manufacturers Can Protect Customers by Eliminating Default Passwords and How Software Manufacturers Can Shield Web Management Interfaces From Malicious Cyber Activity.

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, FBI, and/or NSA:

• Contact CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472) or your local FBI field office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.

Australian organizations: Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and access alerts and advisories.

Canadian organizations: Report incidents by emailing Cyber Centre at contact@cyber.gc.ca.

New Zealand organizations: Report cyber security incidents to incidents@ncsc.govt.nz or call 04 498 7654.

United Kingdom organizations: Report a significant cyber security incident: report.ncsc.gov.uk (monitored 24 hours) or, for urgent assistance, call 03000 200 973.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. The authoring organizations do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by FBI and co-sealers.

Acknowledgements

Schneider Electric, Nozomi Networks, Eversource Energy, Electricity Information Sharing and Analysis Center, Chevron, BP, and Dragos contributed to this advisory.

Version History

December 09, 2025: Initial version.

Appendix A: Targeting Methodologies for Pro-Russia Hacktivist Groups

For further information on targeting methodologies for pro-Russia hacktivist groups, see:

• CISA’s alert Unsophisticated Cyber Threat Actor(s) Targeting Operational Technology;
• The joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology; and
• CISA’s Russia Cyber Threat webpage.

Appendix B: Additional Designators Used for Cited Groups

The cybersecurity industry and cyber actor groups often use various names to reference actor groups. While not exhaustive, the following are the most notable names used within the cybersecurity community to reference the groups in this advisory.

Note: Cybersecurity organizations have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the authoring organizations’ understanding for all activity related to these groupings.

• GRU military unit 74455
  • Sandworm Team
  • Voodoo Bear
  • Seashell Blizzard
  • APT44
• Cyber Army of Russia Reborn (CARR)
  • CyberArmy of Russia
  • Народная CyberАрмия (НКА)
  • People’s CyberArmy of Russia (PCA)
  • Russian CyberArmy Team (RCAT)
• NoName057(16)
  • NoName057(16) Spain
  • NoName057(16) Italy
  • NoName057(16) France
• Z-Pentest
  • Z-Pentest Beograd
  • Z-Pentest Alliance
  • Z-Alliance

Introduction

Note: This advisory was originally published on April 7, 2026, to provide tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) related to ongoing cyber exploitation of internet-connected operational technology (OT) devices by Iranian-affiliated advanced persistent threat (APT) actors. The authoring agencies updated this advisory on July 22, 2026, to add new guidance on detecting malicious changes in reusable code modules leveraged within Rockwell Automation PLC programs. It also expands the manufacturer scope to include observed targeting of Schneider Electric, Siemens, and potentially other branded/manufactured PLCs, emphasizing the importance of restricting direct internet access and providing best practice resources for secure deployment.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Environmental Protection Agency (EPA), Department of Energy (DOE), United States Cyber Command – Cyber National Mission Force (CNMF), and Department of the Treasury (Treasury) (hereafter referred to as the “authoring agencies”) are urgently warning U.S. organizations of ongoing cyber exploitation of internet-connected OT devices—including PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs—across multiple U.S. critical infrastructure sectors. As a result of this activity, organizations from multiple U.S. critical infrastructure sectors experienced disruptions through malicious interactions with PLC project files¹ and the manipulation of data displayed on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays. In a few cases, this activity caused operational disruption and financial loss.

The authoring agencies assess a group of Iranian-affiliated APT actors is conducting this activity to cause disruptive effects within the United States. The group targeted devices spanning multiple U.S. critical infrastructure sectors, including Government Services and Facilities (to include local municipalities), Water and Wastewater Systems (WWS), and Energy Sectors. The authoring agencies previously reported on similar activity targeting PLCs by CyberAv3ngers (aka Shahid Kaveh Group)—a cyber threat actor affiliated with Iran’s Islamic Revolutionary Guard Corps (IRGC) Cyber Electronic Command (CEC).

Due to the widespread use of these PLCs, and the potential for additional targeting of other branded OT devices across critical infrastructure, the authoring agencies recommend U.S. organizations urgently review the TTPs and IOCs in this advisory for indications of current or historical activity on their networks, and apply the recommendations listed in the Mitigations section of this advisory to reduce the risk of compromise.

If owners and operators discover an affected internet-accessible device in their environment, additional technical measures may be necessary to evaluate the risk of compromise. Please engage your cyber incident response plans and contact the authoring agencies and applicable vendors through existing support channels available to customers and integrators (see Contact Information) to receive support, mitigation, and investigation assistance.

For more information on Iranian malicious cyber activity, see CISA’s Iran Threat Overview and Advisories webpage and the FBI’s Iran Threat and Iran Cyber Threat Overview webpages.

Download the PDF version of this report:

(New, July 22, 2026) For a downloadable copy of July 22, 2026 IOCs, see:

• AA26-097A STIX XML (XML, 29 KB)
• AA26-097A STIX JSON (JSON, 30 KB)

For a downloadable copy of historical April 7, 2026 IOCs, see:

Background Information

Similar Historical Activity Targeting Programmable Logic Controllers

During a similar campaign beginning in November 2023, the IRGC CEC-affiliated cyber threat actors known as "CyberAv3ngers” targeted U.S.-based PLCs and HMIs, causing disruptive effects. Private industry and open sources also refer to this group as Hydro Kitten, Storm-0784, APT Iran, Bauxite, Mr. Soul, Soldiers of Solomon, UNC5691, and the Shahid Kaveh Group. These attacks compromised at least 75 devices, targeting U.S.-based Unitronics PLC devices with an HMI used across multiple critical infrastructure sectors, including the WWS. APT actors developed and deployed custom ladder logic code to these devices, replacing the valid ladder logic with malicious code that continues to be observed to date.

For more information on this group’s activity, see the joint Cybersecurity Advisory IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities.

Ongoing Threat Actor Activity Against U.S.-Based Programmable Logic Controllers

The FBI observed Iranian-affiliated APT actors targeting internet-exposed PLCs with the intent to cause disruptions—including maliciously interacting with project files, and manipulating data displayed on HMI and SCADA displays—to U.S. critical infrastructure organizations. Iranian-affiliated APT targeting campaigns against U.S. critical infrastructure have recently escalated, likely in response to hostilities between Iran, and the United States and Israel.

(New, July 22, 2026) At one U.S. victim, the FBI observed the APT actors download a malicious project file to a targeted PLC using configuration software. Analysis indicated the project file retained ladder logic for downstream function but added logic that overrode specific instruction sets responsible for maintaining safe operating parameters in the victim’s environment.

Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT group disrupted the function of PLCs. Organizations across several U.S. critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy Sectors) deployed these PLCs within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 19. See the MITRE ATT&CK Tactics and Techniques section of this advisory for tables of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Initial Access

(Updated, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using several foreign-based IP addresses to access internet-facing PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs [T0883]. The actors used leased, third-party hosted infrastructure and manufacturers’ PLC programming software to connect to misconfigured victim PLCs. Inbound malicious traffic has been observed targeting PLC devices on the following ports: 44818, 2222, 102, and 502, as well as targeting modems on port 22. Targeted devices include:

• Rockwell Automation: CompactLogix and Micro850 PLCs
• Schneider Electric: BMX P34/Modicon M340 PLCs
• Siemens: S7-1200 series PLCs

Command and Control

(Updated, July 22, 2026) The targeting of ports [T0885] associated with other OT vendors’ protocols suggests these actors are opportunistically targeting devices manufactured by companies other than Rockwell Automation/Allen-Bradley, including Schneider Electric and Siemens. In one reported instance, the actors utilized Dropbear Secure Shell (SSH) software on victim modems to enable them to gain remote access through port 22 [T1219].

Exfiltration

(New, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using configuration software—such as Rockwell Automation’s Studio 5000 Logix Designer, Schneider Electric’s EcoStruxure Control Expert, and Siemens’ Totally Integrated Automation (TIA) Portal—on leased, third-party hosted infrastructure to exfiltrate device project files from PLC devices to threat-actor-controlled infrastructure [T1041].

Impact

(Updated, July 22, 2026) After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays [T1565]. Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.

Note: An AOI is analogous to a “Function Block” or “User Defined Function Block” used in other PLC vendor programs.

Indicators of Compromise

See Table 1 and Table 2 for recent IP addresses used by the Iranian-affiliated APT actors to communicate with PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, and Siemens in the United States.

Disclaimer: The FBI observed the threat actors using the IP addresses listed below in the specified time frames. This data is being provided for customers to query against logs for indications of historical targeting by the Iranian-affiliated APT actors. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

MITRE ATT&CK Tactics and Techniques

See Table 3 to Table 6 for all referenced threat actor tactics and techniques in this advisory. The authoring agencies recommend organizations review historical TTPs for similar Iranian-affiliated cyber actor activity in IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Mitigations

The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats and TTPs. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

Network Defenders

The cyber threat actors accessed PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other branded/manufactured PLCs to cause disruptions to victim systems. To safeguard against this threat and threats to other types of PLCs, the authoring agencies urge organizations to consider the following mitigations.

(Updated, July 22, 2026) In addition to contacting the authoring agencies, organizations and integrators operating PLCs from the manufacturers mentioned in this advisory should review the previously issued guidance to strengthen the security of their OT deployments:

• Rockwell Automation: Contact the Rockwell Automation Product Security Incident Response Team (PSIRT) at PSIRT@rockwellautomation.com for questions regarding this guidance, or to report cyber incidents related to Rockwell Automation products.
  
  • Refer to Rockwell Automation Security Advisory SD1771 for recommended PLC hardening measures and configuration guidance.
• Schneider Electric: Contact the Schneider Electric Corporate Product Cyber Emergency Response Team (CPCERT) at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
  
  • Refer to Schneider Electric’s Recommended Cybersecurity Best Practices and Cybersecurity User Guide for Modicon Controller Platform for guidance on securing and configuring PLCs.
• Siemens: Contact Siemens ProductCERT at productcert@siemens.com for questions regarding this guidance, or to report cyber incidents and vulnerabilities related to Siemens products.
  
  • Refer to Siemens Security Bulletin 104599 for a list of security measures to harden PLCs and in-depth configuration guides.
  • Siemens users should review the Cybersecurity for Industry Operational Guidelines and implement defense-in-depth controls within their automation systems.

Immediate steps to prevent the attack:

• Disconnect the PLC from the public-facing internet [CPG 3.S]. Follow the joint guidance Secure connectivity principles for OT to safely allow remote access. Specifically, “remove inbound port exposure,” so the OT system is never directly exposed to the internet or external networks, and to ensure all access is mediated, monitored, and controlled. Do this through a secure gateway (jump host) that brokers the connection.
  
  • Ensure cellular modems, used for remote field connectivity and access, are secured with strong authentication and updated.
  • Enable logs for connected modems and regularly review for suspicious activity to detect intrusions and improve incident response speed.
  • (New, July 22, 2026) To mitigate unauthorized access to OT via cellular modems, organizations should consider implementing isolated architectures, such as private Access Point Name (APN), 5G Public Network Integrated Non-Public Network (PNI-NPN), cellular Software-Defined Wide Area Network (SD-WAN), Zero Trust Network Access (ZTNA), or a site-to-site virtual private network (VPN).
• (New, July 22, 2026) Strictly control network access to PLC devices.
  
  • Configure firewall rules or access control list (ACL) security features on PLCs or programmable controllers to allow only authorized communications between expected control system devices. Block access from unauthorized or threat actor-controlled IP addresses, such as those associated with hosting providers.
• For controllers with a physical mode switch, place the physical mode switch into run position to prevent remote modification. Devices should only be in the program or remote position when updating or downloading software online and immediately switched back to the run position when complete. (See Rockwell Automation’s² System Security Design Guidelines for manufacturer’s instructions.)
  
  • (New, July 22, 2026) Prior to switching the device to run mode, review and validate project files, as changing modes will lock in the current project file downloaded to the device.
• For devices that allow software key switching, enable programming protection in PLC configuration software (S7 TIA Portal) to limit who can modify PLCs remotely. (See Siemens’ Cybersecurity for Industry Operational Guidelines for the manufacturer’s instructions.)

Follow-up steps to strengthen security posture:

• (New, July 22, 2026) Review project files running on PLCs for unauthorized changes. Use vendor-provided integrity checking tools and visually compare the running program to known good logic. Ensure reusable logic and input/output configurations are valid. For Rockwell Automation PLCs listed in the Customer Guidance to Disconnect Devices from the Internet, check the AOIs for any anomalous modifications.
  
  • If restoring from backups, verify the backup does not contain malicious logic before deployment.
  • Review logs and configurations on all connected devices, including modems, HMIs, and workstations, to assess potential lateral movement by threat actors. If it appears the actors connected to additional devices, reimage these devices to remove any potential malicious changes or access tools.
• (New, July 22, 2026) Ensure device passwords are changed from their default and are configured to use complex, unique combinations of letters, numbers, and symbols that are not easily guessable. Implementing robust password practices remains a critical security measure that can help prevent unauthorized access and strengthen the overall security posture of OT devices.
• (New, July 22, 2026) Take defensive measures to minimize the risk of exploitation. Conduct comprehensive impact analysis and risk assessments prior to deploying defensive measures.
• Create and test strong backups of the logic and configurations of PLCs. Store backup files offline and secure the physical removal media to enable fast recovery.
• Implement multifactor authentication (MFA) [CPG 3.F] for access to the OT network from an external network.
• If remote access is required, implement a network proxy, gateway, firewall, and/or VPN in front of the PLC to control network access.
  
  • A VPN or gateway device can enable MFA for remote access even if the PLC does not support MFA. Implement security rules on these higher-level network security mechanisms to prevent the type of repeated and sustained login attempts seen during a brute force attack. When possible, implement a device control list for workstations sending messages or connecting to OT components.
  • Use the device control list to monitor for logon activity for unexpected or unusual access to devices from the internet.
• Keep PLC devices updated with the latest software patches issued by the manufacturer. Use established downtime windows to install patches. Known Exploited Vulnerabilities may need to be prioritized outside a downtime window.
• Configure external and internal firewalls to block traffic using common ports associated with network protocols that are unnecessary for the particular network segment.
• Disable any unused authentication methods, logic, or features, such as default authentication keys and passwords, as well as unused or needed services such as Teletype Network (Telnet), File Transfer Protocol (FTP), Remote Desktop Protocol (RDP), Virtual Network Computing (VNC), and web services.
• Monitor asset management systems for device configuration changes, which can be used to understand expected parameter settings.
• Monitor the content of network traffic for the following:
  
  • Unusual logins to internet-connected devices or unexpected protocols to/from the internet. 
  • Functions of industrial control systems management protocols that change an asset’s operating mode or modify programs.
• (New, July 22, 2026) Ensure service providers are informed of active threats targeting internet-connected PLC devices. Owners and operators should communicate directly with service providers to address risks, especially when remote monitoring or maintenance is involved. Some service providers may rely on internet connectivity essential to monitor and maintain OT/ICS operations but may not be fully aware of active threats.

In addition, the authoring agencies recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques, as well as reduce the impact and risk of compromise by cyber threat actors:

• Reduce risk exposure. CISA offers a range of services at no cost, including scanning and testing, to help organizations reduce exposure to threats via mitigating attack vectors. CISA’s Cyber Hygiene Services can help provide additional review of organizations’ internet-accessible assets. 

Device Manufacturers

Note: The following guidance is general in nature and not specific to any OT vendor. Some of the features, settings, and practices may already be offered by certain vendors. The inclusion of this guidance should not be interpreted as an assertion that vendors referenced do not offer such security features. Also, this advisory is not highlighting a new vulnerability in the identified products, but instead discusses opportunistic targeting. Device manufacturers can make opportunistic attacks more difficult at scale by encouraging more secure behavior by default and in operations, as discussed below. 

Although critical infrastructure organizations using PLC devices can take steps to mitigate the risks, it is ultimately the responsibility of the device manufacturer to build products secured by design and default. The authoring agencies urge device manufacturers to take ownership of their customers’ security outcomes by following the principles in the joint guide Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products, primarily:

• Change the manufacturers’ default settings to prevent exposing administrative interfaces to the internet.
• Do not charge additional fees for basic security features needed to operate the product securely.
• Support MFA, including via phishing-resistant methods.

By using secure by design tactics, software manufacturers can make product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing tiered security software and logs, monitoring, and making routine updates.

For more information on common misconfigurations and guidance on reducing their prevalence, see joint advisory NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations. For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

Validate Security Controls

In addition to applying mitigations, the authoring agencies recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 3 to Table 6).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring agencies recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the ATT&CK techniques identified in this advisory.

Resources

• Authoring Agencies: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities
• CISA: Bulletproof Defense: Mitigating Risks From Bulletproof Hosting Providers
• EPA: Cybersecurity for the Water Sector
• CISA: Water and Wastewater Cybersecurity
• CISA: Exploitation of Unitronics PLCs used in Water and Wastewater Systems
• CISA: Iran Threat Overview and Advisories
• FBI: The Iran Threat and Cyber Threat Overview: Iran
• CISA, MITRE: Best Practices for MITRE ATT&CK Mapping
• CISA: Decider Tool
• CISA: Cross-Sector Cybersecurity Performance Goals 2.0
• CISA: No-Cost Cybersecurity Services and Tools
• CISA: Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products
• NSA, CISA: NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations
• CISA: Secure by Design
• FBI, CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• United Kingdom National Cyber Security Centre: Secure connectivity principles for operational technology

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, the FBI, and/or NSA:

• Contact CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472). File a claim with FBI’s Internet Crime Complaint Center (IC3) or contact your local FBI field office. When available, please include the following information regarding the incident: 
  • Date, time, and location of the incident;
  • Type of activity;
  • Number of people affected;
  • Type of equipment used for the activity; and
  • Name of the submitting company or organization, and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.
• Entities required to report incidents to DOE should follow established reporting requirements, as appropriate. For other energy sector inquiries, contact EnergySRMA@hq.doe.gov.
• Contact the Rockwell Automation PSIRT for questions regarding their guidance or for reporting cyber incidents related to Rockwell Automation products at PSIRT@rockwellautomation.com.
• Contact the Schneider Electric CPCERT at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
• Contact Siemens ProductCERT for up-to-date information about the security of Siemens products or to report cybersecurity vulnerabilities at productcert@siemens.com. For support with increasing the security of installed Siemens PLCs, contact Siemens Industrial Cybersecurity Services at services.automation@siemens.com. See Siemens ProductCERT and Siemens CERT for more information.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA and the authoring agencies do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA and the authoring agencies.

Version History

April 7, 2026: Initial version.

July 22, 2026: Update includes new guidance on detecting malicious activity, expanded scope of observed targeting, and best practices for secure PLCs deployment.

Notes

¹Project file refers to the software file that contains ladder logic and configuration settings. On Rockwell Automation devices, it is referred to as an .ACD file.

² See CompactLogix 5370 Controllers (Chapter 5: “Select the Operating Mode of the Controller”) for more information on functions available for the switch.

Executive summary

Russian Federal Security Service (FSB) Center 16 cyber actors continue to exploit poorly configured and vulnerable networking devices worldwide, opportunistically compromising multiple critical infrastructure sector networks. This joint Cybersecurity Advisory (CSA) builds on FBI’s Russian Government Cyber Actors Targeting Networking Devices, Critical Infrastructure Public Service Announcement of the decade-plus FSB Center 16 cyber activity by providing additional tactics, techniques, and procedures (TTPs) to enable defenders to more fully understand and counter the threat. [1] 

This CSA is being released by the following authoring and co-sealing agencies: 

• United States National Security Agency (NSA)
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Federal Bureau of Investigation (FBI)
• United States Department of Defense Cyber Crime Center (DC3)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Communications Security Establishment Canada’s (CSE’s) Canadian Centre for Cyber Security (Cyber Centre)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)¹ 
• Danish Defence Intelligence Service (DDIS)² 
• Estonian Foreign Intelligence Service (EFIS)³ 
• Estonian Information System Authority (RIA)⁴
• Finnish Defence Intelligence (FDI)⁵
• Finnish Security and Intelligence Service (SUPO)⁶
• French National Cybersecurity Agency (ANSSI)⁷
• Italian External Intelligence and Security Agency (AISE)⁸ 
• Italian Internal Intelligence and Security Agency (AISI)⁹
• The Military Counterintelligence Service of Poland (SKW)¹⁰ 
• Sweden National Cyber Security Centre (NCSC-SE)¹¹ 

The authoring and co-sealing agencies strongly urge device owners and network defenders to take mitigation and remediation actions against Russian government-sponsored exploitation of vulnerable routers.

Download the PDF version of this report:

• Improve Router Hygiene to Protect Against Russian State-Sponsored Targeting (PDF, 816KB)

Cybersecurity industry tracking 

The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to this activity. Although not all encompassing, the following list contains the most notable threat group names commonly used within the cybersecurity community related to this activity: 

• Berserk Bear 
• Energetic Bear
• Crouching Yeti 
• Dragonfly
• Ghost Blizzard
• Static Tundra

Note: Cybersecurity companies have different methods of tracking and attributing cyber actors, and this list may not provide a 1:1 correlation to the authoring agencies’ understanding for all activity related to these groupings.

Targeting details

Critical infrastructure sectors most at risk from the Russian Federal Security Service (FSB) Center 16 cyber actors’ targeting include:

• Communications,
• Defense Industrial Base,
• Energy,
• Financial Services,
• Government Services and Facilities, especially organizations at the state and local level, and
• Healthcare and Public Health.

Technical details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise¹² framework, version 19. See Appendix A for tables of the activity mapped to MITRE ATT&CK tactics and techniques. This advisory also uses MITRE DEFEND^TM version 1.4.0.

The Russian FSB Center 16 cyber actors primarily use scanning to identify poorly configured networking devices, primarily routers, for exploitation. The actors scan for Internet IP ranges with active Simple Network Management Protocol (SNMP) agents that accept common or default community strings for authentication [T1595.001, T1595.002]. These scans, run via proxies, consist of SNMP Set-Requests from a spoofed IP address [T1027] containing Object Identifiers (OIDs) that instruct the SNMP agent on poorly configured networking devices to [T1569, T1602.001, T1090]:

• Copy its configuration to a file, often called “config.bkp” or “output.txt” [T1003, T1602.002].
• Transfer the file, typically using Trivial File Transfer Protocol (TFTP), to an actor-controlled leased virtual private server (VPS) or compromised FTP server [T1583.003, T1090, T1071, T1048].

While SNMP scanning is the primary method the actors use to discover and exploit poorly configured networking devices, they occasionally exploit common vulnerabilities and exposures (CVEs) in Cisco devices, Cisco’s Smart Install (SMI) functionality, and web portals to manage network devices. The actors previously exploited at least the following CVEs [T1584.008, T1588.005, T1190, T1068]: 

• CVE-2018-0171
• CVE-2008-4128¹³

Many of these TTPs overlap with activity by other malicious cyber actors, such as Salt Typhoon. Even though this CSA focuses on Russian FSB Center 16 cyber activity, the mitigations below should detect and counter these and similar TTPs used by other actors.

Mitigation actions

The authoring agencies highly recommend network defenders implement the following mitigations to harden networks against this exploitation:

• Disable Cisco Smart Install on all devices [D3-ACH]. [2]
• Use SNMPv3 with “authPriv” configured to the most modern encryption standard that is supported by the device instead of SNMPv1 or SNMPv2 [D3-ACH]. [3]
  • Disable SNMPv1 and SNMPv2. These are legacy protocols and should no longer be needed on current devices. If they are necessary, change all community strings from defaults and only allow read-only community strings rather than read-write access.
  • SNMPv3 adds strong authentication and data encryption that are unavailable in SNMPv1 and v2. SNMPv3 replaces clear text shared passwords, known as community strings, with more securely encoded parameters, and authenticates and encrypts data [D3-MAN, D3-MENCR].
• Use strong, unique passwords for local accounts on network devices and configure credentials to be stored securely to prevent reuse of compromised passwords [D3-CH].
  • Cisco devices protect passwords in the configuration file using different hashing types. Use hashing type 8 for user credentials. Avoid using hashing type 0, 4, and 7 as they are insecure or store passwords in plaintext in the configuration file. [4]
  • Monitor for unusual credentials that do not conform to standard organizational naming conventions [D3-PM]. 
  •  Monitor for and alert on logins using local accounts. Local accounts should only be used in emergency situations when accounts supported by centralized authentication servers are unavailable. Centralized authentication to network devices should support multi-factor authentication where feasible. [3]
• Monitor and restrict access to SNMP OIDs using a Management Information Base (MIB) allow list [D3-ACH]. [5] Reference the vendor-specific MIB for the network devices and monitor OIDs for indications of reconnaissance or misconfiguration in logs or intrusion detection systems (IDS). IDS rules should be written for inbound SNMP Set-Requests that contain OIDs targeting sensitive device data [D3-PM].
  
  • Example OIDs include:
    • 1.3.6.1.4.1.9.9.96.1.1 (Cisco Config Copy)
    • 1.3.6.1.4.1.9.9.96.1.1.1.1.5 (Config Copy Server Address, value for this OID is where the configuration file is being sent to) 
• Restrict management protocols [D3-NTF].
  • Use Access Control Lists (ACLs) to only allow management protocols, such as SNMP, from management devices, preferably on an out-of-band network. [3]
  • On edge firewalls and devices deny all external communications on the following ports unless mission critical, with strict monitoring if blocking is not feasible:
    • User Datagram Protocol (UDP) port 69 (TFTP) 
    • Transmission Control Protocol (TCP) port 4786 (SMI)
    • UDP ports 161 and 162 (SNMP)
    • TCP/UDP ports 10161 and 10162 (SNMPv3)
• Update network device software and firmware images, especially to patch known vulnerabilities, and upgrade end-of-life devices to supported ones. 
  
  • Use an attack surface management service to identify and secure Internet-facing systems with weak configurations and known vulnerabilities [D3-NVA].
    • U.S.-based federal, state, local, tribal, and territorial governments and U.S. critical infrastructure organiztions should consider signing up for CISA’s no-cost Cyber Hygiene services.
    • U.S. Defense Industrial Base organizations should consider signing up for NSA’s DIB Cybersecurity Services.

Resources

United States:

• Russia Threat Overview and Advisories
• Network Infrastructure Security Guide

Canada:

• Routers cyber security best practices (ITSAP.80.019)
• Security considerations for edge devices (ITSM.80.101)
• Guidance on securely configuring network protocols (ITSP.40.062)
• Baseline security requirements for network security zones (ITSP.80.022)
• Top 10 IT security actions to protect Internet-connected networks and information (ITSM.10.089)

Works cited

[1] FBI. Russian Government Cyber Actors Targeting Networking Devices, Critical Infrastructure. Alert Number: I-082025-PSA. 2025. https://www.ic3.gov/PSA/2025/PSA250820

[2] NSA. Cisco Smart Install Protocol Misuse. 2017. https://media.defense.gov/2019/Jul/16/2002157833/-1/-1/0/CSA-CISCO-SMART-INSTALL-PROTOCOL-MISUSE.PDF

[3] NSA. Network Infrastructure Security Guide. 2023. https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF

[4] NSA. Cybersecurity Information Sheet Cisco Password Types: Best Practices. 2022. https://media.defense.gov/2022/Feb/17/2002940795/-1/-1/0/CSI_CISCO_PASSWORD_TYPES_BEST_PRACTICES_20220217.PDF

[5] NSA. Cybersecurity Information Sheet: Reducing the Risk of Simple Network Management Protocol (SNMP) Abuse. 2026. https://media.defense.gov/2026/Jul/09/2003959459/-1/-1/0/CSI_REDUCING_RISK_OF_SNMP_ABUSE.PDF

Footnotes

¹  Národní úřad pro kybernetickou a informační bezpečnost

²  Forsvarets Efterretningstjeneste

³ Välisluureamet

⁴ Riigi Infosüsteem Amet

⁵ Sotilastiedustelu

⁶ Suojelupoliisi

⁷ Agence nationale de la sécurité des systèmes d’information

⁸ Agenzia Informazioni e Sicurezza Esterna

⁹ Agenzia Informazioni e Sicurezza Interna

¹⁰ Służba Kontrwywiadu Wojskowego

¹¹ Nationellt Cybersäkerhetscenter

¹² MITRE and ATT&CK are registered trademarks of The MITRE Corporation. MITRE DEFEND is a trademark of the MITRE Corporation.

¹³ CVE-2008-4128 only affects end-of-life Cisco devices.

Disclaimer of Endorsement

The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

United States organizations

• National Security Agency (NSA)
  • Cybersecurity Report Feedback: CybersecurityReports@nsa.gov 
  • Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov 
  • Media Inquiries / Press Desk: NSA Media Relations: 443-634-0721, MediaRelations@nsa.gov
• Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI)
  •  U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA via the agency’s Incident Reporting System, its 24/7 Operations Center (report@cisa.gov or 888-282-0870), or your local FBI field office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment user for the activity; the name of the submitting company or organization; and a designated point of contact. 
• United States Department of Defense Cyber Crime Center (DC3)  
  • Defense Industrial Base Inquiries and Cybersecurity Services: DC3.DCISE@us.af.mil 
  • Defense Industrial Base mandatory cyber incident reporting as required by 10 U.S. Code Sections 391 and 393 and Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012 is submitted at https://dibnet.dod.mil.
  •  Media Inquiries / Press Desk: DC3.Information@us.af.mil

Australian organizations

• Australian Signals Directorate
  • Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and access alerts and advisories.

Canadian organizations

• The Canadian Centre for Cyber Security (Cyber Centre), part of the Communications Security Establishment, encourages Canadian organizations to report cyber incidents and to strengthen the security of their networking devices. 
  • Report an incident or suspicious activity to the Cyber Centre by email at contact@cyber.gc.ca, online via the reporting tool Report a cyber incident - Canadian Centre for Cyber Security or by phone at 1-833-CYBER-88 (1-833-292-3788).

New Zealand organizations

• New Zealand National Cyber Security Centre (NCSC-NZ): info@ncsc.govt.nz

United Kingdom organizations

• Report significant cyber security incidents to ncsc.gov.uk/report-an-incident (monitored 24/7)

Estonia organizations

• Estonian Foreign Intelligence Service (EFIS): info@valisluureamet.ee

Finnish organizations

• Finnish Security and Intelligence Service: supo.fi/en/contact

French organizations

• French organizations are encouraged to report suspicious activity or incident related information found in this advisory by contacting ANSSI/CERT-FR at: cert-fr@ssi.gouv.fr or by phone at: 3218 or +33 9 70 83 32 18.

Italian Organizations

• Italian External Intelligence and Security Agency (AISE): 
  • Visit https://www.sicurezzanazionale.gov.it/ 
• Italian Internal Intelligence and Security Agency (AISI): 
  • Visit https://www.sicurezzanazionale.gov.it/ 

Appendix A: MITRE ATT&CK tactics and techniques

See Table 1 through Table 10 for all the threat actor tactics and techniques referenced in this advisory.

Appendix B: MITRE D3FEND countermeasures

See Table 11 for a mapping of several of the cybersecurity countermeasures mentioned in this advisory.

Bots (and privacy-preserving browsers) not welcome

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome.

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors.

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans.

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate.

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse.

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers.

The Costs of Convenient Solutions

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors.

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.

A Better Path Forward

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit.

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work.

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms.

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage.

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking.

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.

The Foundations

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to.

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history.

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them.

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you.

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably.

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour.

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected.

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked.

Putting it together

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C CG Meeting in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens.

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites.

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it.

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time.

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one.

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy.

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor.

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction.

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism.

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.

Next Steps

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community.

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need.

Acknowledgements

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun. 

The post PACT: Anonymous Credentials for the Web appeared first on Mozilla Hacks - the Web developer blog.

In November 2023, a large cache of his wartime papers—nicknamed the “Bayley papers”—was auctioned in London for almost half a million U.S. dollars. The previously unknown cache contains many sheets in Turing’s own handwriting, telling of his top-secret “Delilah” engineering project from 1943 to 1945. Delilah was Turing’s portable voice-encryption system, named after the biblical deceiver of men. There is also material written by Bayley, often in the form of notes he took while Turing was speaking. It is thanks to Bayley that the papers survived: He kept them until he died in 2020, 66 years after Turing passed away...

NOTE: we'll update the FOSDEM 2023 playlist as we gather all the talks. Stay tuned for more Matrix content.

This video was recorded during FOSDEM 2023, and can also be found here: https://fosdem.org/2023/schedule/event/matrix20/

Matrix is an open standard for secure, decentralised communication, which may be familiar from powering the online editions of FOSDEM in 2021 and 2022 (and hybrid-FOSDEM this year!).

In this talk we will explain the fundamental changes which are landing in Matrix 2.0, which speeds up Matrix to be at least as snappy as the fastest proprietary messaging apps - all while handling thousands of rooms spanning millions of users.

During 2022 we've been on a mission to completely rework the slowest bits of Matrix, aiming that nobody can ever complain about Matrix being sluggish again. In practice this means fundamental changes in:

- How Matrix syncs data - "sliding sync", where servers only sync the bare minimum data to clients required to render the UI, providing instant login and instant sync (MSC3575)

- How room joins work over federation - "faster joins", where servers only sync the bare minimum data such that clients can start participating in the room as soon as possible (MSC3902)

- How auth works - switching Matrix to use OIDC natively for all authentication, registration and account management (MSC3861)

- How VoIP works - switching Matrix to natively support multiparty decentralised E2EE VoIP as the primary calling mechanism (MSC3401 and MSC3898)

The end result is transformational, and by far the biggest change to Matrix since the project began in 2014. So, we're calling it Matrix 2.0, and this talk will give a guided tour of everything that's changed - and show off the new reference matrix-rust-sdk client SDK, which powers the new flagship mobile Matrix client, codenamed Element X.

00:00 Hello!
00:41 Matrix and its ecosystem
06:33 Spec update
08:10 Matrix is taking over the world
09:26 Demo: Element X is blazing fast
13:25 Behind the scenes of the demo
15:02 How sliding sync works
21:20 One matrix-rust-sdk to rule them all
23:45 Faster remote room joins
25:12 MatrixRTC, Element Call, Matryoshka Widgets
26:37 Demo: Element Call!
28:34 Demo: raiding Element Call with waterfall — Selective Forwarding Units for Matrix
31:02 OpenID Connect: authentication done right
32:04 The future: Digital Markets Act, MIMI, MLS, P2P Matrix
36:32 Demo: P2P Matrix
40:31 Demo: ThirdRoom — Matrix beyond chat and voice
47:16 What's next?

Support Matrix!
🪙 Donorbox for individuals - https://donorbox.org/keep-matrix-exciting
💶 Matrix Foundation (paid) membership for orgs - https://forms.gle/Yy345QkB5pifJJNy6

(This Week in) Matrix
🐘 https://mastodon.matrix.org/@matrix
🐦️ https://twitter.com/matrixdotorg
[m] https://matrix.to/#/#thisweekinmatrix:matrix.org

WhatsApp ermöglicht es jetzt auch auf dem iPhone, zwei Accounts gleichzeitig auf einem Gerät zu nutzen. Damit lassen sich etwa private und berufliche Chats bequem trennen, ohne ständig Konten wechseln oder eine zweite App verwenden zu müssen. Wir zeigen dir, wie die Einrichtung funktioniert. Android-Nutzer haben bereits seit 2023 die Möglichkeit, zwei WhatsApp-Konten gleichzeitig auf […]

Der Beitrag WhatsApp: So kannst du zwei Accounts gleichzeitig auf dem iPhone nutzen erschien zuerst auf BASIC thinking. Folge uns auch auf Google News und Flipboard oder abonniere unseren Newsletter UPDATE.

Google Sheets now offers enhanced support for combo charts, providing a more seamless experience when creating multi-series visualizations. | Learn more.

A centralized hub for meeting resources on the new Google Meet homepage

Finding the right notes or attachments for a meeting shouldn't feel like a scavenger hunt. We’re introducing a revamped Google Meet homepage on the web to help you stay organized and prepared throughout your entire meeting workflow. | Learn more.

Redesigned Google Classroom homepage with tailored views based on user’s role

Soon, Google Classroom will introduce a redesigned homepage globally across all editions to help teachers, students, and administrators easily find relevant content, resources, and tools tailored to their specific roles. | Learn more.

Gemini Alpha is now Gemini Beta

We’re updating the name of the Gemini Alpha program to "Gemini Beta." This new name more accurately reflects both the scale and the quality of the features that enter this launch stage. Please note that this is solely a branding change. This update does not alter any customer configurations, data privacy constraints, or pricing tiers. | Learn more.

Google Meet now organizes your meeting notes, transcripts, and recordings in your Google Drive

We’re making it easier for users to find meeting notes, transcripts and recordings in Google Drive. | Learn more.

View supporting calendar delegates in meeting guest list

When viewing a guest list in Google Calendar on the web, you will now see a new icon next to leaders who have a calendar delegate assisting them with scheduling support. Hovering over the icon will display the person’s information, allowing you to easily initiate a chat with them directly. | Learn more.

The announcements above were published on the Workspace Updates blog over the last week. Please refer to the original blog posts for complete details.

Tags: #Firefox | #Mozilla

Roman und Fabian sprechen heute über ein iPhone-Leasing-Modell, eine geplante KI-Beratung in der Apple Store-App, neue Gerüchte zum iPhone Ultra und dem vorerst abgesagten Paramount-Deal. ... Weiterlesen ...

Der Beitrag iPhone-Leasing | KI im Apple Store | iPhone Ultra – Apfelplausch #454 erschien zuerst auf Apfelpage.

The post WhatsApp Expands Beyond Messaging With CarPlay, iPad, and Productivity Upgrades appeared first on TechRepublic.

Tags: #Cyber Security | #Künstliche Intelligenz

The post Examining the Unintended Consequences of the Online Safety Act appeared first on IT Security Guru.

Google Fined Over Self-preferencing on Google Search

Google Play Restrictions Lead to Second Fine

Digital Markets Act Enforcement Brings Compliance Deadline

Commission Investigations Began in 2024

Instagram geht verstärkt gegen Nutzer vor, die mit Kamerabrillen heimlich fremde Personen filmen und die Aufnahmen anschließend als Belästigungs-, Prank- oder Anmache-Videos veröffentlichen. Neben einzelnen Beiträgen können künftig auch die verantwortlichen Konten von der Plattform entfernt werden. Instagram-Chef Adam Mosseri erklärte, dass Inhalte gelöscht werden, wenn sie andere Menschen ausnutzen oder belästigen. Gemeint sind insbesondere […]

The post Heimlich gefilmt: Instagram sperrt Nutzer von Meta-Brillen first appeared on ifun.de.

Apple TV verabschiedet sich im kommenden Jahr von einer seiner prägendsten Serien. „The Morning Show“ wird nach der fünften Staffel beendet. Während Jennifer Aniston und Reese Witherspoon damit auf die Zielgerade einbiegen, startet heute mit „The Dink“ eine neue Sportkomödie rund um den Pickleball-Boom. „The Morning Show“ endet 2027 Apple hat bestätigt, dass die fünfte […]

The post Apple TV: Letzte Staffel für „The Morning Show“ first appeared on ifun.de.

Tags: #Exchange | #Microsoft | #Störung