For decades, Network Address Translation (NAT) has been the default way IP addresses are provided inside larger networks, as a means to deal with the challenges of IPv4 address availability.

The basic premise behind NAT is that private addresses stay private, but that assumption might not be entirely accurate anymore (if it ever really was). At Black Hat USA 2026, researcher Malcolm Stagg, an independent researcher and Synack Red Team member, disclosed NatJack, an attack class that manipulates the NAT connection tracking table. 

An attacker sharing a NAT boundary with a victim can hijack active connections, poison DNS responses, and force denial of service, without the IP spoofing or broadcast domain access older Layer 2 attacks required. Thirteen vendors were notified, and testing covered 32 products and configurations across 95 reports. Every tested implementation was vulnerable to some or all of the NatJack techniques.

Stagg didn’t intentionally set out to find flaws in NAT, but he found them. “I kind of ran into this attack entirely by accident,” Stagg told Network World. “I noticed that I was sometimes getting responses that didn’t correspond to the packets that I was sending. That told me that there is some sort of corruption happening inside the NAT table.”

What breaks in the NAT trust model

NAT was never built as a security control. It emerged in the early 1990s as a stopgap for IPv4 address exhaustion, letting multiple devices share one public IP address under an assumption of trust between peers.

“I think it basically goes back to under-specification in some of the RFCs that just allow behaviors based on the assumption that you’re in a network where the peers are trusted,” Stagg said.

NAT has been hacked before. Security researcher Samy Kamkar disclosed NAT Pinning at DEF CON 18 and Black Hat in 2010, an early technique for manipulating NAT port behavior. He returned to the problem a decade later with NAT Slipstreaming, disclosed in 2020 and expanded with Armis researchers in 2021, which abused Application Level Gateway (ALG) connection tracking and required a victim to visit a malicious website. Those flaws have all been patched.

NatJack is different. It manipulates the NAT table directly, needs no ALG, and requires no victim action beyond an active connection through the same NAT.

The flaw does not stop at Layer 2. VLAN segmentation and switch port isolation do not help, since the attack targets shared NAT infrastructure at Layer 3 and Layer 4 rather than the local broadcast domain. The flaw was confirmed across Windows, Linux, and macOS despite no shared NAT codebase, pointing to a shared design assumption rather than an isolated bug.

Four attack techniques, one shared weakness

NatJack covers four distinct techniques, all built on the same weakness in how NAT tables track connections.

• TCP connection hijacking. An attacker forces a victim’s connection into a closed state using spoofed packets, then replaces the resulting table entry with one pointing to the attacker. The RFC 1337 TIME-WAIT Assassination mechanism Stagg identified lets this happen in a handful of packets rather than a standard connection timeout.
• DNS response poisoning. The technique intercepts and alters UDP DNS responses passing through the NAT, redirecting a victim’s lookups without their knowledge.
• Denial of service. An attacker exhausts the NAT table itself, breaking connectivity for every device sharing that NAT.
• Connection port identification. An attacker determines which port a NAT has assigned to an active connection, information that can support the other three techniques.

Disclosure and a mixed vendor response

Stagg responsibly disclosed the flaw, though vendor reaction has varied widely, from formal patches to outright rejection. 

The Linux kernel security team initially dismissed the report, going so far as to call the report- totally bogus. Stagg said the response caught him off guard. “I was pretty surprised by that,” Stagg said. “Getting that response was a little bit unexpected, and a little discouraging.”

The kernel was eventually patched at Microsoft’s request to support Azure Kubernetes Service, resulting in CVE-2026-63913. Microsoft’s own Windows NAT vulnerability, affecting Hyper-V, was assigned CVE-2026-56181.

Other vendors declined to classify the findings as vulnerabilities. “These reports are design-level NAT limitations rather than security vulnerabilities,” Cisco PSIRT said. “There are documented mitigations for the Cisco Secure Firewall and Cisco IOS XE products which would prevent most, if not all of these issues.”

Apple took a similar position. “We’ve determined the behavior reflects a known limitation of the transport layer rather than a vulnerability,” Apple Product Security said. “Modern security models assume the local network may be hostile. This is why we continue to rely on end to end encryption, such as TLS.”

Stagg noted that while encryption blunts the worst outcomes of NatJack, it does not eliminate the risk. “Encryption is a great help here because an attacker can still hijack a connection, but if they do, they can’t send or receive any data over that connection unencrypted,” Stagg said. “An attacker can still target and remove any of those connections.”

Detection and mitigation

Even without full patches available, there are steps that network professionals can take to limit risk. Stagg suggests the following:

• Monitor for compromise indicators. Watch for a full or near-full NAT table, floods of TCP or UDP packets across a wide port range, the same IP address appearing at two physical locations, and anomalous SYN or RST packet sequences.
• Enable source IP protection. Turn on protections such as IP Source Guard to block spoofed packets at the router or firewall.
• Segment untrusted traffic. Place untrusted users on a separate subnet or VLAN, and cap connections per client at roughly under 10,000.
• Disable loose connection modes. Turn off loose connection tracking, port preservation, and endpoint-independent mapping where supported.
• Restrict container network access. Disable network access for untrusted containers and Kubernetes workloads, avoid running as root, and drop default capabilities.
• Isolate cloud workloads. Keep untrusted and trusted workloads off the same NAT gateway, and use dedicated IPs for serverless workloads.

“One of the attack variations does still work in cases where the attacker and victim are located in different subnets,” Stagg said.

Stagg said the underlying lesson of NatJack extends beyond any single patch.

“A lot of networks are vulnerable to this, and you can’t always rely on the Layer 2 isolations that are in place,” Stagg said. “When you’re relying on historical design choices, those threat models might not be the same now as they were back then. It’s important to look at those design assumptions and see if there are any updates that might be necessary based on the new threat models.”

Given the widespread enterprise adoption of passkeys to replace passwords, a Palo Alto Networks Unit 42 report disclosing ways attackers are getting around passkey protections is concerning, analysts say, but they stress that the demonstrated attacks can only happen after a successful intrusion.

They also pointed out that the issues are not strictly caused by holes in passkeys so much as by weaknesses in the procedures surrounding them. 

“The researchers didn’t break the underlying cryptography. They exploited the seams around it: onboarding flows, recovery mechanisms and trust signals that weren’t being validated,” said Justin Greis, CEO of consulting firm Acceligence. “That distinction matters because it tells us where the actual risk lives.”

The Palo Alto report showed attacks that, it said, “demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts,” as well as “how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys.”

Palo Alto described three categories of attack, collectively dubbed Pass-ta-key: Pass-ta-key, where an attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction; Silver Pass-ta-key, which involves an attacker tricking Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication; and Golden Pass-ta-key, which allows an attacker to extract all synced passkeys in a form that lets them be shared or sold on the credential black market.

Given the complexity of most global enterprise threat surfaces, some CISOs have struggled with adapting passwordless processes to environments with legacy and virtual environments. Passcodes have been recently embraced by enterprise CISOs as the first step in implementing a passwordless strategy.

Analysts and consultants in the main agreed that the flaw Palo Alto reports is significant, despite the fact that it assumes the attacker has already penetrated an environment and successfully installed malware. Sadly, given that such penetration only requires one privileged user anywhere to accidentally click on a poisoned link or attachment, the assumption of prior penetration is likely valid.

Implementation issues are the problem

What the report reveals is less about any flaws within passcodes directly, and more about the lack of attention paid to a wide range of mechanisms surrounding them. 

Greis said CISOs now need to focus on what to do, and what to test, based on the assumption that user behavior is not always as expected. 

In several cases cited in the report, he pointed out, issues occurred “not because the standard is flawed, but because implementations haven’t caught up to it. It mirrors what we’ve seen repeatedly in security: the specification is sound, but the ecosystem implementing it is uneven.”

Consultant Brian Levine, executive director of FormerGov, agreed. 

“On any service where your organization is the relying party, require user verification and actually validate the user-verified flag in the authentication response,” he said. “The researchers found real-world services accepting logins without it, which quietly collapses a multi-factor login back into a single factor.”

Frank Dickson, group VP for security at IDC, added that he would stress to CISOs that this attack assumes a prior successful penetration. 

“This isn’t passkeys getting hacked from across the internet. It’s what [an attacker] does once they’re already inside the house. So the real headline is that ‘phishing resistant’ stops being resistant the moment the endpoint stops being clean,” he said.

“Stop treating verification as optional,” he advised. “Flip it to required, check it server side every single time, and save your hardware bound keys, the YubiKeys of the world, for the accounts that matter most. A key that never leaves a physical device is a key no attacker can ever harvest in bulk.”

Or Finkelstein, head of marketing at Secret Double Octopus, agreed that CISOs have gotten complacent about the way in which systems support passkeys.

“CISOs should probably look at how user verification is enforced, how enrollment and recovery work, have a clear and enforced policy on whether credentials are synced or device-bound, and have some ITDR system to quickly mitigate suspicious endpoints and authenticators,” he said. “In most serious enterprise environments, EDR and device management reduce the likelihood of initial attacks, but do not close every post-compromise attack path.”

Poor support processes weaken passkeys

Some have argued that the lack of sufficiently robust support processes actually weakens passkey capabilities and undermines the whole point of such systems.

J. Wolfgang Goerlich, a member of the faculty of IANS and a longtime cybersecurity consultant, pointed out that the original FIDO2 spec eliminated credential theft by binding the private key to a physical authenticator. Synced passkeys reintroduced credential portability and therefore reintroduced the form of credential theft risk cited in the Palo Alto report.

“A passwordless system is exactly as strong as the flow that re-establishes it,” he said. “Both serious techniques here start by forcing a device to re-enroll. Many security teams have never modeled, never monitored and never rehearsed a response to this.”

Goerlich’s advice to CISOs is to require device-bound authenticators, such as hardware tokens or computers, for all privileged and sensitive access. They may consider allowing wallets for lower risk access, he said, “however, much like passwords in Web browsers have long been at risk, we must now consider passkeys in the browsers an unacceptable risk.”

This article originally appeared on CSOonline.

AI note-taking app maker Granola is accused of violating privacy laws by developing software that can record conversations without all participants’ consent, according to a lawsuit filed July 30 in a California federal court.

It follows a similar ongoing case in the same district, filed last year, that involves another note-taking and transcription software vendor, Otter.ai.

AI note-taking apps have proliferated in recent years, with dedicated tools emerging from vendors including Fellow, Fireflies, Otter, and others, some of which claim to have tens of millions of users. These AI assistants record and transcribe meeting conversations, generating automated summaries and follow-up items. Similar note-taking functionality is also built into virtual meeting platforms such as Google Meet, Microsoft Teams, and Zoom.

However, the use of these AI note-taking tools has raised privacy concerns over the ability of some to record and transcribe conversations without the consent of all participants.

The proposed class action complaint against Granola, filed by Florida resident Tarra Chamberlain in the US District Court for the Northern District of California, alleges the company “purposefully” designed its app to record calls without requiring disclosure to all participants.  

While some note-taking tools require a bot to join a video or voice call, Granola captures audio directly from the user’s computer, allowing it to transcribe meetings without appearing as a meeting participant.

The complaint argues that this violates individual privacy rights as well as the California Invasion of Privacy Act (CIPA) that requires “all-party” consent when recording calls.

The complaint also alleges that Granola then by default uses transcription data for commercial purposes, including its use in training its AI models, and “actively advertises the hidden nature of its technology as one of its primary advantages.”

Granola did not respond to a request for comment.

According to the company’s website, Granola offers two optional “transparency features” that can be enabled by app users and admins: an automated chat message that alerts participants when transcription begins, and a watermark added to the user’s video feed. The company also promises that data used to train its AI models is anonymized and “never sent to third parties.”

The Granola case bears similarities to a separate lawsuit involving Otter.ai. The class action filed last year alleges that Otter.ai records all users without their consent and uses their voices to train its speech recognition AI tools.

Reporting on the latest developments in the Otter.ai suit, MLex wrote this week that, during a court hearing Monday, the judge overseeing the case expressed skepticism about the company’s argument to dismiss the case. US District Judge Eumi K. Lee did not issue a ruling from the bench, saying a written judgement would follow.

The two cases highlight some of the concerns businesses face when deploying AI note-taking tools.

AI notetaking is “more dangerous than any other type of traditional recording apps and tools,” said Enza Iannopollo, Forrester VP and principal analyst, as it raises additional questions about the use of employees’ conversation data.

“Specifically, is the recorded data used for training models? Is the voice used for training other AI? How do I get ‘forgotten’ after my data and biometrics have been recorded? These concerns apply to AI specifically and must be added to the traditional privacy and confidentiality concerns organizations have for other type of recording apps and tools,” she said.

Before deploying AI note-taking apps, Iannopollo recommends that businesses take appropriate steps to vet the tools and “ensure that all contractual clauses are aligned to the business AI risk appetite and risk management best practices.”

“As these tools record, process, store, and share biometric data, organizations must ensure that they comply with all the relevant requirements,” Iannopollo said, adding that transparency and consent notices should be provided to all parties involved in the use of AI note-taking apps.