protobuf

Cybersecurity researchers have flagged half a dozen vulnerabilities in protobuf.js, a JavaScript and TypeScript implementation of Protocol Buffers (Protobuf), that, if successfully exploited, could result in remote code execution (RCE) and denial-of-service (DoS) attacks. "In affected environments, a single malicious protobuf schema, descriptor, or crafted payload could be enough to trigger crashes, runtime corruption, or even code execution," Cyera security researcher Assaf Morag said. The vulnerabilities have been codenamed Proto6. Protobuf is a free and open-source, language-agnostic mechanism for serializing structured data. It was originally developed and used internally by Google before it was made publicly available in 2008. The identified vulnerabilities affect Node.js applications that use protobuf.js, Google Cloud client libraries, messaging frameworks like Baileys, and CI/CD pipelines. Per Cyera, any Node.js service that deserializes Protobuf data or generates code from schemas with protobuf.js is likely impacted as well. A brief description of each of the flaws is below - CVE-2026-44289 (CVSS score: 7.5): DoS through unbounded protobuf recursion CVE-2026-44290 (CVSS score: 7.5): Process-wide DoS when loading schemas with unsafe option paths CVE-2026-44291 (CVSS score: 8.1): Code generation gadget after prototype pollution CVE-2026-44292 (CVSS score: 5.3): Prototype injection in generated message constructors CVE-2026-44294 (CVSS score: 5.3): DoS from crafted field names in generated code CVE-2026-44295 (CVSS score: 8.7): Code injection in pbjs static output from crafted schema names Cyera said all the vulnerabilities stem from the library's handling of schema and metadata as trusted by default. This validation oversight could influence application behavior and lead to code execution. "While exploitation of these vulnerabilities generally requires specific conditions, those conditions are increasingly common in data and AI ecosystems that routinely exchange data, schemas, and configuration files across services, repositories, cloud platforms, and third-party integrations," Morag noted. In a potential attack scenario, a bad actor could introduce a malicious protobuf schema to poison CI/CD workflows, leaking build secrets in the process (CVE-2026-44295), or crash Node.js services such as WhatsApp bots built using Baileys, a WhatsApp Web API automation TypeScript library, by means of a specially crafted message (CVE-2026-44292). The most severe of the lot is CVE-2026-44291, which results in code execution when a Node.js application accepts attacker-controlled input. "That input reaches a prototype pollution gadget," security researcher Vladimir Tokarev explained. "Later, the same process uses protobuf.js to encode or decode a message. Because protobuf.js resolves type names through plain property lookups, a polluted Object.prototype can make an attacker-controlled string look like a valid protobuf primitive." "Protobuf.js then inserts that string into a generated encoder or decoder function and compiles it with Function(). The attacker gets arbitrary JavaScript execution inside the Node.js process." The following versions of the tool are vulnerable - protobuf.js: versions = 8.0.0 = 2.0.0 <= 2.0.1 Patches for the flaws are available in protobufjs 7.5.6 and 8.0.2, and protobufjs-cli 1.2.1 and 2.0.2. Users are advised to apply the latest fixes to safeguard against potential threats. "Because protobuf.js is heavily used inside databases, vector stores, inference pipelines, orchestration systems, CI/CD tooling, and cloud SDKs, successful exploitation could impact sensitive enterprise and AI workloads at scale," Cyera said. "Modern software increasingly treats schemas, metadata, and configuration files as trusted inputs that drive automation, orchestration, and code generation. When those trust assumptions break, data can become behavior. That shift creates new attack surfaces that security teams must learn to identify and manage."

Microsoft's GitHub repositories have become the latest to fall victim to the ongoing Miasma self-replicating supply chain attack campaign. The incident impacted 73 Microsoft repositories across four of its GitHub organizations, including Azure, Azure-Samples, Microsoft, and MicrosoftDocs, per OpenSourceMalware. The development has prompted GitHub to disable access to those repositories. "Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service," reads the message when attempting to access the "Azure/azure-functions-host" repository. "If you are the owner of the repository, you may reach out to GitHub Support for more information." According to OpenSourceMalware, some of the repositories impacted by the incident are listed below - azure-search-openai-demo-purviewdatasecurity Connectors-NET-LSP Connectors-NET-SDK durabletask durabletask-dotnet durabletask-go durabletask-js durabletask-mssql functions-container-action homebrew-functions llm-fine-tuning windows-driver-docs What's notable about the latest campaign is the re-compromise of the "durabletask" PyPI package, which was infected by TeamPCP last month to deliver an information stealer on Linux systems. "A month later, not only is Azure/durabletask gone - so is every sibling repo in the Durable Task ecosystem, sitting one org over in Microsoft: the .NET, Go, Java, JS, MSSQL, Netherite, and protobuf implementations, plus the Durable Functions monitor," security researcher Paul McCarty (aka 6mile) said. "When the repo at the root of last month's compromise is the hub of this month's takedown, that is not a coincidence - that is the same wound reopening. Whoever held those credentials in May plausibly never fully lost them." Miasma is assessed to be a variant of the Mini Shai-Hulud worm that TeamPCP publicly released in mid-May 2026. It has since continued to mutate and refine its tactics, even as it has infected more packages over the past couple of days, using various descriptions for the newly-created public repositories containing the stolen secrets - Miasma: The Spreading Blight Miasma : The Spreading Blight Miasma - The Spreading Blight Hades - The End for the Damned As of writing, there are 13 repositories with the description "Hades - The End for the Damned" and 82 repositories with the remaining three naming patterns. Miasma has also been observed skipping the npm registry entirely, with the threat actors pushing malicious code directly to "icflorescu/mantine-datatable" and four related repositories: "mantine-contextmenu," "next-server-actions-parallel," "mantine-datatable-v6," and "mantine-contextmenu-v6." "The commit added no dependencies. It planted a 4.3 MB payload runner and wired it to execute automatically through five developer tools: Claude Code, Gemini CLI, Cursor, VS Code, and the npm test script," SafeDep said. "The attack detonates when a developer clones one of the affected repos and opens it in an AI coding agent. The dropper is the same staged Bun loader, here repurposed for GitHub source-repo persistence rather than registry poisoning." These software supply chain attacks have exposed the underlying weaknesses in the trust model that forms the basis of software delivery in open-source ecosystems, making it one of the most significant and sustained campaigns observed to date. What separates the activity from other incidents is its ability to exponentially propagate across the ecosystem by compromising downstream users and repeating the same cycle. "The worm's genius and the reason conventional defences largely failed is that it operates entirely within legitimate channels. It does not exploit a vulnerability in npm or GitHub," FalconFeeds.io said. "It exploits the trust model those platforms are built on: the assumption that if a package is signed with a valid key and published by an authenticated maintainer, it is safe." "Shai-Hulud compromises the key and the maintainer, then proceeds to act exactly as a legitimate publisher would. From the registry's perspective, every malicious publish event is indistinguishable from a routine update." Update When reached for comment, a Microsoft spokesperson told The Hacker News via email that "we have temporarily removed some repositories as we investigate potential malicious content." StepSecurity, in a report published June 5, 2026, said the same contributor account behind the May compromise of the durabletask PyPI package was used to push a malicious commit in the latest incident. "Instead of poisoning a package registry, the commit planted configuration files that trigger automatic code execution when a developer opens the repository in an AI coding tool or IDE," security researcher Ashish Kurmi said. The commit has been found to add five files designed to achieve code execution across four different developer tools - .claude/settings.json, by embedding an Anthropic Claude Code SessionStart hook that causes the payload to be executed automatically whenever a session starts. .gemini/settings.json, by embedding a Google Gemini CLI SessionStart hook that causes the payload to be executed automatically whenever a session starts. .cursor/rules/setup.mdc, by embedding a prompt injection that instructs the Cursor AI agent to execute the payload by treating it as a project setup requirement. .vscode/tasks.json, by embedding a Microsoft Visual Studio Code auto-run task through the "runOn: folderOpen" option. "The fact that the same account was used again means one of three things happened," StepSecurity said. "The account's credentials were never fully rotated after May 19, and the attacker retained a working GitHub token." "The contributor was re-compromised through the worm's own propagation loop: opening an infected repository in an AI coding tool would have harvested fresh tokens. A different contributor's token was used with the commit author metadata spoofed via the Git Data API."

Details USN-8063-1 fixed a vulnerability in Protocol Buffers. This update provides the corresponding update for Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. Original advisory details: It was discovered that Protocol Buffers incorrectly handled recursion when the Python google.protobuf.json_format.ParseDict() function is being used. An attacker could possibly use this issue to cause Protocol Buffers to consume resources, resulting in a denial of service. USN-8063-1 fixed a vulnerability in Protocol Buffers. This update provides the corresponding update for Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. Original advisory details: It was discovered that Protocol Buffers incorrectly handled recursion when the Python google.protobuf.json_format.ParseDict() function is being used. An attacker could possibly use this issue to cause Protocol Buffers to consume resources, resulting in a denial of service. The problem can be corrected by updating your system to the following package versions: Reduce your security exposure Ubuntu Pro provides ten-year security coverage to 25,000+ packages in Main and Universe repositories, and it is free for up to five machines.

Proof-of-concept exploit code has been published for a critical remote code execution flaw in protobuf.js, a widely used JavaScript implementation of Google's Protocol Buffers. The tool is highly popular in the Node Package Manager (npm) registry, with an average of nearly 50 million weekly downloads. It is used for inter-service communication, in real-time applications, and for efficient storage of structured data in databases and cloud environments. In a report on Friday, application security company Endor Labs says that the remote code execution vulnerability (RCE) in protobuf.js is caused by unsafe dynamic code generation. The security issue has not received an official CVE number and is currently being tracked as GHSA-xq3m-2v4x-88gg, the identifier assigned by GitHub. Endor Labs explains that the library builds JavaScript functions from protobuf schemas by concatenating strings and executing them via the Function() constructor, but it fails to validate schema-derived identifiers, such as message names. This lets an attacker supply a malicious schema that injects arbitrary code into the generated function, which is then executed when the application processes a message using that schema. This opens the path to RCE on servers or applications that load attacker-influenced schemas, granting access to environment variables, credentials, databases, and internal systems, and even allowing lateral movement within the infrastructure. The attack could also affect developer machines if those load and decode untrusted schemas locally. The flaw impacts protobuf.js versions 8.0.0/7.5.4 and lower. Endor Labs recommends upgrading to 8.0.1 and 7.5.5, which address the issue. The patch sanitizes type names by stripping non-alphanumeric characters, preventing the attacker from closing the synthetic function. However, Endor comments that a longer-term fix would be to stop round-tripping attacker-reachable identifiers through Function at all. Endor Labs is warning that “exploitation is straightforward,” and that the minimal proof-of-concept (PoC) included in the security advisory reflects this. However, no active exploitation in the wild has been observed to date. The vulnerability was reported by Endor Labs researcher and security bug bounty hunter Cristian Staicu on March 2, and the protobuf.js maintainers released a patch on GitHub on March 11. Fixes to the npm packages were made available on April 4 for the 8.x branch and on April 15 for the 7.x branch. Apart from upgrading to patched versions, Endor Labs also recommends that system administrators audit transitive dependencies, treat schema-loading as untrusted input, and prefer precompiled/static schemas in production. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Passwordless authentication is often presented as the end of account takeover. But to understand the real threat landscape, we need to examine how passwordless is actually deployed in the real world. Attackers do not break protocols in theory. They target the most common implementations, the places where usability, scale and architecture intersect. Focusing on one of those common implementations, we examine Google Cloud Authenticator. This discussion explores the hidden mechanisms behind synced passkeys and their implementation within the Google ecosystem. Our aim is to help defenders better understand the technology, to lay the groundwork to show how new attack vectors could emerge in a passwordless environment. This post is Part 2 in our series examining passkey adoption from a security perspective. If you haven’t read Part 1 yet, we recommend starting here: The Art of the Invisible Key – Passkey Global Breakthrough. Palo Alto Networks customers are better protected from threats that take advantage of issues with cloud authentication through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. When we set out to evaluate the security of passkeys, we deliberately thought like attackers. Instead of asking whether Fast IDentity Online (FIDO) is secure, we asked where passkeys live, how they move, how they sync and which components handle the most sensitive operations. That shift in perspective revealed a surprisingly broad and largely unexplored attack surface. Many of the findings we uncovered have not been publicly discussed, and we will reveal them throughout this series. However, before diving into new attack vectors, we need to establish a clear architectural foundation. The FIDO and W3C specifications define the authentication protocols in detail, but the real protection of key material often extends beyond those documents. In practice, critical implementation details are embedded in browsers, operating systems and cloud services, and are rarely described publicly. We therefore began with one of the most widely adopted passwordless ecosystems: Google’s passkey authentication. In this article, we examine the architecture behind synced passkeys for desktop users and explore the lesser known Google Cloud Authenticator, a cloud-based component that performs sensitive cryptographic operations. Once we understand how this system is built, we can analyze the new attack vectors it introduces and discuss how to mitigate them in the next part of this series. Disclaimer: This analysis reflects our understanding of a complex, evolving system, based on client code, runtime behavior, network traces and public sources. The research detailed here was conducted for responsible, ethical security analysis. To keep the discussion readable, we simplify certain internal flows and use illustrative pseudocode. Although the Google Cloud Authenticator is used by Chrome across platforms, our focus here is Chrome on Windows with Trusted Platform Module (TPM) support. Whenever users authenticate with passkeys backed by Google Password Manager (GPM) across desktop platforms (macOS, Windows, Linux and ChromeOS), we see a connection to the domain enclave.ua5v[.]com. As of January 2026, searching for enclave.ua5v[.]com yields surprisingly little public information about its role in passkey authentication (as shown in Figure 1). This is despite powering logins worldwide. The FIDO specifications do not explicitly define a cloud-based authenticator. However, related building-block elements exist in Client-to-Authenticator Protocol (CTAP) Hybrid transports, where Bluetooth Low Energy (BLE) physical proximity can be used to establish a tunnel service to Google’s caBLE.ua5v[.]com domain. While Chrome still leverages portions of the Hybrid (caBLE) transport code, understanding the actual implementation requires examining Chrome’s behavior and the cloud authenticator, as observed through its network interface and Chromium source code (as shown in Figure 2). Onboarding Device A Chrome user can perform passkey operations synchronized with their Google account, making passkeys available across all connected devices. Before any passkey can be used, Chrome runs a dedicated onboarding flow behind the scenes (shown in Figure 3). This allows the remote Google Cloud Authenticator to verify both the device’s identity and the user’s possession of it. To establish trust between the device and the cloud authenticator, Chrome assigns two TPM-backed key pairs: Identity key: Represents “something you have.” In WebAuthn terms: “Register a particular client device as a ‘trusted device’, so the client device itself acts as a something-you-have authentication factor for future authentication.” User verification key (UV key): Represents “something you know or are.” This key can only be created or used after the user authenticates (verifies) with the same method they use to unlock the device (biometric or PIN). After generating the device keys, the client sends a registration request to the cloud authenticator. The message includes: Commands: "device/register", "keys/genpair" Identity_public_key: Public key corresponding to the TPM-protected identity key. UV_public_key: Public key corresponding to the TPM-protected UV key. Device_id: SHA256 hash of the identity public key (SPKI). The cloud authenticator creates a new record and stores the device’s hardware-backed public keys associated with the device ID: devices[device_id] = { hw: identity_public_key, uv: uv_public_key } In addition, the cloud authenticator generates and stores a device-specific wrapping key. This key is used to encrypt secrets, allowing them to be stored on the device as opaque blobs and unwrapped only by the cloud authenticator: wrapping_keys[device_id] = random(32) Finally, the cloud authenticator generates a member key pair. The private member key is encrypted with the wrapping key. This key is then returned along with the public member key intended for joining the device as a trusted member within the account’s security domain of authorized devices: (member_private_key, a member_public_key) = Generate P-256 key pair wrapped_member_private_key = encrypt(member_private_key, key:wrapping_key) On the first device, the onboarding process also includes generating the account secrets: Security domain secret (SDS): A symmetric master key used by the cloud authenticator to encrypt and decrypt all synced passkeys for the account GPM PIN Code: A user-chosen secret that allows newly added devices to access the account’s synced passkeys Figure 4 shows the start of the recovery PIN process. Establishing a security domain backed by Google’s Trusted Vault service, linking the user’s authorized devices and managing the encryption keys used by Chrome Sync to securely synchronize passkeys Creating a PIN-protected recovery mechanism to store and recover the SDS securely During the first passkey operation on a new device or on a recovered account, Chrome prompts the user to verify with the same GPM PIN. The PIN is verified by the cloud authenticator and protected recovery mechanism. This allows the device to join the account’s security domain, synchronize account passkeys and enable the cloud authenticator to wrap the SDS for that device. To summarize the device onboarding process, we can review the various key materials generated during the onboarding and stored in a file under the user’s profile directory: %LocalAppData%\Google\Chrome\User Data\ \passkey_enclave_state. The local file enables future device-cloud communication without re-registration or re-entering the PIN and includes the following elements: Device keys: - Identity key: - wrapped_identity_private_key: When Chrome creates the identity key, it asks the TPM to seal the private portion with the TPM’s hard-coded key. This allows the key to be saved as an opaque blob that only that specific TPM can unseal. - identity_public_key: The corresponding public portion. - device_id: The hash of the identity public key that is used as a unique identifier for the device within the cloud authenticator - UV key - wrapped_uv_private_key: The label of the hardware-backed key that is gated by local (Windows Hello) user verification - uv_public_key: The corresponding public portion Identity key: wrapped_secret: The SDS encrypted with the cloud authenticator’s wrapping key wrapped_pin: PIN data encrypted under the cloud authenticator’s wrapping key, enabling the authenticator to verify the PIN, enforce retry limits and perform secure PIN updates without ever exposing the plaintext PIN Figure 5 shows the extracted passkey_enclave_state file. After the device onboarding — which involves completing enrollment with the cloud and joining the security domain — the device's user can start creating and using passkeys that are securely synchronized with their Google account. Figure 6 shows the flow for this process. When a user chooses to add a passkey as an authentication method to a service, the relying party (service) invokes a create WebAuthn API: navigator.credentials.create(options) Chrome then displays a prompt offering to save the passkey in GPM as shown in Figure 7. Once the user selects the GPM option, Chrome prepares the required data and initiates a secure, peer-to-peer (P2P) encrypted session with the cloud authenticator. Create Command (Chrome to Cloud Authenticator) Chrome sends a request containing the following parameters: command: "passkeys/create" device_id wrapped_secret Key Generation and Encryption (Cloud Authenticator to Chrome) The cloud authenticator performs the following operations: Uses the provided device_id to locate the corresponding stored wrapping_key. Unwraps the wrapped_secret to recover the SDS. Generates a new P-256 ECDSA key pair for the passkey. Encrypts the passkey’s private key using the SDS. Returns the public key and the encrypted private key to the Chrome client. wrapping_key = wrapping_keys[device_id] security_domain_secret = decrypt(wrapped_secret, key: wrapping_key) (passkey_private_key, passkey_public_key) = Generate P-256 key pair encrypted_private_key = encrypt(passkey_private_key, key:security_domain_secret) Return to the device (passkey_public_key, encrypted_private_key) Passkey Registration (Chrome to Relying Party) Chrome forwards the passkey public key to the relying party as part of the WebAuthn registration response. The website stores this public key under the user’s account for future authentication. Passkey Synchronization (Chrome to Security Domain) Next, Chrome prepares a protobuf-encoded sync entity named WebauthnCredentialSpecifics. This record represents the cloud authenticator’s encrypted view of the new credential, enabling any device enrolled in the same security domain to access and use it for authentication. Each WebauthnCredentialSpecifics entry includes: RP ID (relying party’s domain) Username Passkey public key Passkey encrypted private key Chrome uploads this sync entity to the Security Domain service, which distributes the update to the other registered devices. Whenever a new passkey is added to the account, each enrolled device stores the corresponding WebauthnCredentialSpecifics locally in Chrome’s sync database: %LocalAppData%\Google\Chrome\User Data\ \Sync Data\LevelDB. The stored record allows GPM to list the accounts' passkeys and make them available for authentication. Figure 8 shows the authentication flow. Log in With Synced Passkey Once a passkey has been created and synchronized, a user can initiate login to a relying party using the synced passkey from any enrolled device. The relying party then invokes a get WebAuthn API: navigator.credentials.get(options). Chrome locates the WebauthnCredentialSpecifics entity that matches the visited relying party ID and establishes a secure connection to the cloud authenticator. Assertion Request (Chrome to Cloud Authenticator) Chrome sends a request containing: Command: "passkeys/assert" client_data_json (challenge and rpID from WebAuthn request) device_id wrapped_secret WebauthnCredentialSpecifics The cloud authenticator performs the following operations: Uses the provided device_id to locate the corresponding wrapping_key Unwraps the wrapped_secret to recover the SDS Decrypts the passkey’s encrypted_private_key with the SDS Sets the authenticator flags, including the user-verified flag, based on whether the client’s message is signed with the user verification key (see the secure communication protocol in the Secure Communication Protocol section) Constructs authenticator_data, which includes: relying party ID (hash), flags and signature counter (always zero) Using the passkey_private_key, signs the concatenation of the client_data_json and the authenticator_data Returns to the client AuthenticatorAssertionResponse containing the client_data_json, authenticator_data and the signature wrapping_key = wrapping_keys[device_id] security_domain_secret = decrypt(wrapped_secret, key: wrapping_key) passkey_private_key = decrypt(WebAuthnCredentialSpecifics.encrypted_private_key, key:security_domain_secret) flags = { flag_user_present = 1, flag_user_present = 1 if user-verified else 0, flag_backup_eligible = 1, flag_backed_up_state = 1, } signature_counter = 0 rpId_hash = SHA_256(rpId) authenticator_data = {rpId_hash, flags, signature_counter} signed_data = authenticator_data + client_data_json assertion_signature = sign(signed_data, key:passkey_private_key) return to the client: AuthenticatorAssertionResponse { clientDataJSON: client_data_json, authenticatorData: authenticator_data signature: assertion_signature, userHandle: WebauthnCredentialSpecifics.credential_id } Chrome forwards the AuthenticatorAssertionResponse to the relying party, which verifies the signature using the previously registered passkey_public_key and authenticates the user. All requests sent to the cloud authenticator, including device management, key handling, recovery operations and passkey creation or use, are protected by a secure communication protocol. For example, once a WebAuthn API is issued and the user selects GPM as the passkey provider, Chrome initiates secure communication with the cloud authenticator as shown in Figure 9. Chrome uses a Google OAuth2 access token as the primary authorization signal for cloud authenticator operations. This token is issued for the Google account that is currently signed in. The token includes a dedicated scope: hxxps[:]//www.googleapis[.]com/auth/secureidentity.action. To obtain the token, Chrome exchanges a locally stored refresh token for a short-lived access token using Google’s OAuth2, as shown in Figure 10. Once the token is obtained, Chrome opens a WebSocket connection to the cloud authenticator. See Figure 11, wss[:]//enclave.ua5v[.]com/enclave. The cloud authenticator returns a WebSocket upgrade response (101 Switching Protocols), and Chrome proceeds to the Noise-NK handshake. Chrome and the cloud authenticator establish an encrypted session using the Noise Protocol Framework. Noise is a framework for flexible cryptographic handshakes that specifies a protocol for two parties to exchange Diffie-Hellman (DH) public keys. It then hashes the DH results into a shared secret and derives symmetric keys to protect all subsequent messages. Chrome uses the following handshake variant: Noise_NK_P256_AESGCM_SHA256. This combination defines: NK: the handshake pattern - N: the initiator (Chrome client) is unauthenticated - K: the responder (cloud authenticator) has a known static public key (the key is hard-coded in Chrome) P256: DH uses the NIST P-256 elliptic curve. AESGCM: encryption uses AES-GCM. SHA256: hashing uses SHA256. The session begins in an initial handshake state, where both sides prepare to exchange ephemeral keys and progressively mix cryptographic material into the handshake hash state and shared encryption key. Chrome sends the first handshake message, which includes its ephemeral public key and the result of an Elliptic Curve Diffie-Hellman (ECDH) operation with the cloud authenticator’s static public key. The cloud authenticator responds with its own ephemeral public key and performs a second ECDH operation using Chrome’s ephemeral key. To this message, the cloud authenticator also attaches an attestation signature for its Oak execution environment, intended to allow the client to verify that it is communicating with a trusted authenticator. We did not observe where, or if, Chrome validates this attestation. After the handshake messages are exchanged, Chrome and the cloud authenticator share a symmetric transport key and a handshake hash. Chrome can then send requests over the secure tunnel, each signed with a device key bound to the handshake. The device-to-cloud request is signed with one of the device’s hardware-backed keys. (The only exception is the initial onboarding message, which carries the device public keys.) For each request, Chrome determines which device key to use based on the context. When WebAuthn’s user verification is required or preferred, Chrome signs the request with the UV key, prompting the local user to verify before signing. When user verification is discouraged, Chrome uses the identity key instead. To bind each request to the active Noise session, Chrome creates a signature over both a serialized Concise Binary Object Representation (CBOR)-encoded request and the handshake hash. The signature not only proves the device's hardware identity and the integrity of the requested message, but also binds it to the current encrypted session. Below is an example using a passkeys/assert request. (Other device-to-cloud authenticator requests follow a similar structure, with the request fields changed.) requests = { "cmd": "passkeys/assert", "request": {rpId, challenge, userVerification,..,} "protobuf": WebauthnCredentialSpecifics, "wrapped_secret": wrapped_secret, "client_data_json": clientDataJSON } serialized_requests = CBOR.encode([requests]) serialized_requests_hash = sha256(serialized_requests) to_sign_message = handshake_hash || serialized_requests_hash Using Windows TPM-Backed Keys for the Signature For the identity key, Chrome signs the message using the Windows Cryptography Next Generation (CNG) APIs: NCryptOpenStorageProvider: Opens the MS_PLATFORM_CRYPTO_PROVIDER NCryptImportKey: Imports and unseals the wrapped_identity_private_key within the TPM NCryptSignHash: produces the signature on the message using the imported key When Chrome needs to sign with the UV key, it calls RequestSignAsync using the UV key label loaded from the passkey_enclave_state file. Windows Hello handles the user verification step, and after approval, Windows performs the actual signing inside the TPM and returns the resulting signature. With the signature ready, Chrome appends it to the request, encrypts it with the shared transport key and sends it over the WebSocket tunnel. request_body_map = { "sig": signature, "device_id": device_id, "auth_level": "uv", // or "hw" tag if signed with identity key "encoded_requests": serialized_requests } encode_message = CBOR.encode(request_body_map) // Make the final message length a multiple of 32 bytes message = encode_message || zero padding || pad_length_byte encypted_massage = noise.encrypt(message) websocket.send(encypted_message) The cloud authenticator decrypts the message using the shared transport key and verifies the signature using the stored device public key associated with the device_id. After processing the request, it prepares a CBOR-encoded response and encrypts it with the same transport key, and then sends it back to the client. Google Cloud Authenticator marks a fundamental shift in how passkeys are created, protected and used across devices. Passwordless authentication has traditionally followed two distinct paths: Hardware-bound keys, which offer strong protection but are locked to a single device Software-based keys, which sync easily but are far more vulnerable to theft The cloud authenticator introduces a new hybrid model. Sensitive key operations are moved to an isolated cloud environment. Every request remains anchored to hardware-backed keys on the user’s device. This approach allegedly preserves hardware-level assurances while enabling the global usability needed for seamless, synchronized cross-device authentication and recovery. This analysis lays the groundwork for highlighting the strengths of cloud-based authenticators. It sets the stage for an upcoming third post, where we’ll explore the new attack vectors in passwordless authentication. This includes cloud-based weaknesses that could allow a remote attacker to impersonate an existing synced device and obtain valid passkey authentication. Palo Alto Networks customers are better protected from threats that take advantage of issues with cloud authentication through the following products and services: Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) and Identity Threat Detection and Response (ITDR). It provides clients with the necessary capabilities to improve their identity-related security requirements. By providing Cortex Cloud visibility into which identities are adding devices or altering their permissions within cloud environments, Cortex Cloud can accurately detect misconfigurations, unwanted access to sensitive data and real-time analysis surrounding usage and access patterns. CyberArk Identity Protection continuously maps authentication configurations and access posture across your human identity environment. It surfaces risks that passwordless deployments can obscure: accounts missing phishing-resistant MFA, misconfigured OAuth token lifetimes, dormant identities with persistent access, and privilege gaps lacking just-in-time controls. Its threat detection capabilities monitor for anomalous authentication patterns and suspicious access behaviors in real time. This enables security teams to identify and respond to identity-based attacks before they escalate, including cases where the initial access vector exploits trusted authentication flows like passkeys or synced credentials. Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Open-source flow monitoring with SENSOR: Benefits and trade-offs Flow monitoring tools are useful for tracking traffic patterns, planning capacity, and spotting threats. But many off-the-shelf solutions come with steep licensing costs and hardware demands, especially if you want to process every packet. A research team at the University of Tübingen has built an alternative: an open-source, cost-effective, and distributed platform for collecting unsampled IPFIX data. Their system, called SENSOR, uses open-source software and vendor-agnostic components to monitor traffic at multiple points in the university’s network. This setup captures internal flows that would otherwise go unnoticed if monitoring were only done at the perimeter. The approach avoids the need for expensive routers with built-in flow exporters and instead uses mirror ports and general-purpose servers running software-based flow meters. Flow monitoring platform at the University of Tübingen How it works At the core of the platform are two types of flow meters: high-performance servers running the open-source tool yaf, and MikroTik routers using a custom configuration to generate IPFIX from mirrored traffic. For backbone and datacenter traffic, the team uses servers with 100 Gbit/s NICs and yaf configured to use the PF RING library for packet processing. yaf supports plugins for deep packet inspection, application labeling, and even DHCP-based OS identification. For access-level monitoring, the team turned to MikroTik routers. These devices don’t normally support passive flow monitoring from mirror ports. But the researchers found a workaround. By creating a bridge and forcing traffic through RouterOS’s firewall stack, they were able to get MikroTik’s “traffic flow” feature to generate usable IPFIX data, even though the packets weren’t originally forwarded by the device. This lets them use a relatively low-cost router with a powerful CPU to collect flow data without modifying the rest of the network. Collecting and processing flows On the collection side, the platform uses several tools in parallel: nfacctd to replicate flows, nfdump and SiLK for analysis and storage, and GoFlow2 for format conversion. GoFlow2 standardizes flows into JSON or Protobuf and sends them to Apache Kafka, which lets downstream components process them as events. The team also uses flowpipeline to build analysis workflows, including anonymization and metrics extraction. By mixing and matching collectors, the system can support different use cases and allow for custom pipelines. Each component is replaceable and modular, which helps tailor the platform to performance needs or analysis goals. Why it matters Most flow monitoring setups rely on embedded flow meters that are locked to a vendor and require powerful, expensive devices. SENSOR shows it’s possible to build a flexible and scalable alternative using only open tools and commodity hardware. It also allows operators to monitor internal traffic more comprehensively, not just what crosses the network border. Boris Lukashev, CTO at Semper Victus & InferSight, told Help Net Security that the ability to collect unsampled flows with open tools is valuable, but context matters. “Sampling works well for network engineering but is less effective for security operations. Vendor approaches vary, and if someone exfiltrates a few bytes over a segment sampled at 100:1, you might miss it entirely. Some vendors still capture it even when ‘off-sample’ because it’s stored in the device’s internal flow tables.” Lukashev says the paper makes a fair point, but the pipeline the researchers built feels heavier than necessary unless you need advanced enrichment with deterministic latency. “Full line-rate NIDS taps are typically beyond the scope of most network engineering teams that support security, and they require architectural planning before purchase to be effective. Flow collection is much simpler as long as it starts at the actual packet processing point, whether that’s the dataplane, ring 0, or wherever the work happens,” Lukashev explained. The system is already deployed at the University of Tübingen, and the team plans to expand their work by benchmarking the performance limits of the flow meters and packet processing libraries involved. Understanding where those limits lie will help ensure that monitoring stays unsampled even at higher traffic volumes. Scaling beyond small networks David Montoya, Global Business Development Manager OT/IoT at Paessler, calls SENSOR “a great example of how to use open-source technologies to overcome a lack of enterprise-grade equipment while still granting access to in-depth traffic analysis.” But he also cautions that it is “based on technologies that are not the first choice for a large network or an ISP.” While MikroTik routers play a key role in SENSOR, David points out that these devices are aimed at small and medium-sized businesses rather than large enterprises. They fill routing gaps effectively and affordably, but he sees limited use for them at scale compared to equipment from Cisco, Juniper, Huawei, or Nokia. He notes that enterprise-class routers from the major vendors already ship with embedded IPFIX, NetFlow v9, or jFlow, along with the processing power to handle traffic sampling. These can connect directly to collectors and integrate with other monitoring protocols such as SNMP for volume tracking, RMON for data corruption detection, and QoS tools for measuring jitter and packet loss. Together, these provide a broader operational view. The limitation with SENSOR, he says, is that while it offers detailed flow visibility, it doesn’t unify these other protocols in one interface. For a large network, that can make troubleshooting and oversight more complex. “Something like this is fine for small networks,” David explains, “but it certainly complicates troubleshooting and oversight on larger networks.” David also sees potential for SENSOR to expand beyond historical analysis by adding real-time alerting. “The paper doesn’t describe whether the flow collectors can trigger alarms for anomalies like rapidly spiking UDP traffic, which could indicate a DDoS attack in progress. Adding real-time triggers like this would be a valuable enhancement that makes SENSOR more operationally useful for network teams.” Hardware and performance caveats Leo Valentić, CEO at RESILIX, highlights hardware-related constraints in SENSOR’s design. “The main limitation is that the MikroTik bridge workaround sends mirrored traffic through the CPU instead of dedicated switching hardware. This limits performance, makes the setup less robust, and creates a bottleneck in high-throughput environments that can lead to dropped packets or incomplete flow data, which undermines the goal of unsampled monitoring.” Valentić notes there is also a risk of drops or inconsistencies in flow exports, since the device is not designed to handle passive mirrored traffic this way and can behave unpredictably under load. “Finally, the approach is fragile. It relies on precise bridge and firewall configurations to push traffic through the RouterOS stack, which makes it sensitive to updates, misconfigurations, or hardware changes. In production environments where reliability is critical, this would be hard to justify,” he concluded. For now, SENSOR is best seen as a capable, budget-friendly option for historical analysis and targeted monitoring, with room to grow if real-time alerting and greater scalability are added. Must read: 35 open-source security tools to power your red team, SOC, and cloud security GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!