CVE-2026-44288

What it actually does

protobufjs versions before 7.5.6 and 8.0.2 contain a non-conformant minimal UTF-8 decoder that accepts overlong UTF-8 byte sequences and normalizes them into their canonical characters instead of rejecting or replacing them. If an application validates or filters raw protobuf binary input before protobufjs decodes string fields, an attacker can encode restricted ASCII characters using overlong byte sequences so the pre-decode check does not see them, while the application later receives a decoded string containing those characters. The primary impact is integrity-related validation bypass in applications that rely on byte-level filtering, deny lists, routing checks, policy checks, or delimiter checks before protobuf string decoding.

Why it matters to the business

Applications using vulnerable protobufjs versions may accept data that was intended to be blocked, potentially allowing attackers to bypass input validation, policy enforcement, routing restrictions, or business-rule checks. The practical severity depends heavily on how decoded protobuf strings are used: in some systems this may only allow malformed data to be stored, while in others it could enable unauthorized actions, injection into downstream logic, or circumvention of access-control-adjacent checks. The issue is not listed in CISA KEV, has low EPSS at the time of assessment, and has no reported exploit maturity, but protobuf parsing libraries are often widely embedded in services and dependencies, so exposure should be addressed through dependency upgrades and validation review.

How an attack unfolds

An attacker first identifies an endpoint, message broker, API, or service path that accepts protobuf binary messages decoded by a vulnerable protobufjs version. The attacker then determines whether the application performs validation against the raw protobuf bytes before protobufjs converts string fields into JavaScript strings. If the application blocks or inspects certain ASCII characters at the byte level, such as delimiters, separators, path characters, or policy-sensitive symbols, the attacker crafts a protobuf message where those characters are represented using overlong UTF-8 encodings. The raw byte filter may not match the prohibited character because the literal ASCII byte is absent. When protobufjs later decodes the field, the overlong sequence is normalized into the canonical character, causing the application to process a string value that should have been rejected. The attacker then uses the bypassed character or string content to influence downstream application behavior, such as validation decisions, command construction, query construction, path interpretation, authorization logic, or data integrity controls, depending on the consuming application.

How to fix it

Upgrade protobufjs to a fixed version: use 7.5.6 or later on the 7.x line, or 8.0.2 or later on the 8.x line. Regenerate lockfiles and redeploy applications, containers, serverless packages, and bundled frontend or backend artifacts that include protobufjs. Because this flaw can also be introduced transitively, review dependency trees with package-manager tooling such as npm ls protobufjs, yarn why protobufjs, or pnpm why protobufjs, and update parent packages where needed. As a defense-in-depth measure, perform validation after protobuf decoding on canonical JavaScript strings rather than only on raw binary input, reject malformed or non-canonical UTF-8 at trust boundaries where possible, and prefer allow-list validation over deny-list checks for security-sensitive fields.

How to confirm the fix worked

Confirm dependency resolution shows protobufjs version 7.5.6 or later, or 8.0.2 or later, in every deployed artifact. Verify lockfiles, software composition analysis results, container image contents, and runtime package inventories rather than only package.json declarations. Add or run regression tests that submit protobuf string fields containing overlong UTF-8 encodings for security-sensitive ASCII characters and confirm they are rejected, replaced, or otherwise cannot bypass application validation. Review code paths to ensure validation occurs on decoded strings and that security decisions are not based solely on raw protobuf byte inspection. For services that expose protobuf interfaces, validate that updated deployments are serving traffic and that old containers, cached build artifacts, and serverless versions have been retired.

Typical attack path

1. Locate an externally reachable or attacker-controllable interface that accepts protobuf binary data.
2. Confirm or infer that the service uses protobufjs before version 7.5.6 or 8.0.2 to decode protobuf string fields.
3. Identify application-level validation that inspects raw protobuf bytes or performs filtering before protobuf string decoding.
4. Craft protobuf binary input containing overlong UTF-8 encodings for characters the application attempts to block.
5. Submit the crafted protobuf message to the target service.
6. Rely on the vulnerable protobufjs decoder to normalize the overlong byte sequence into the prohibited canonical character.
7. Trigger downstream logic that trusts the decoded string and processes data that should have failed validation.

How to detect it

To determine whether exploitation already occurred, focus on services that accept protobuf binary input from untrusted sources and used vulnerable protobufjs versions before remediation. Review API gateway, load balancer, service, application, and message-consumer logs for unusual protobuf requests, validation bypass symptoms, parser warnings, unexpected delimiters or path characters appearing after decode, and business-rule exceptions involving string fields. If raw request bodies, message payloads, packet captures, dead-letter queues, or rejected-message archives are available, search for overlong UTF-8 byte sequences that encode ASCII characters, especially two-byte overlong forms beginning with C0 or C1 followed by 80-BF. Compare pre-decode validation logs with post-decode application values where available; suspicious cases include raw payloads that do not contain a blocked ASCII byte but decoded strings that do contain the blocked character. Also review downstream effects such as unexpected route names, identifiers, paths, separators, query fragments, policy fields, or command-like strings appearing shortly after protobuf ingestion. There are no known public threat actors or KEV-driven campaigns associated with this issue based on the supplied data, so detection should be behavior- and payload-focused rather than actor-focused.

• C0 AF
• E0 80 AF
• F0 80 80 AF
• C0 AE
• E0 80 AE
• F0 80 80 AE
• C0 BC
• C0 BE
• C0 A2
• C0 A7
• C0 A6
• C0 80
• C1 80
• C1 BF
• /node_modules/protobufjs/
• protobufjs@7.5.5
• protobufjs@7.5.4
• protobufjs@7.5.3
• protobufjs@7.5.2
• protobufjs@7.5.1
• protobufjs@7.5.0
• protobufjs@8.0.1
• protobufjs@8.0.0

What your security team should do

• Inventory all applications and services that include protobufjs directly or transitively, prioritizing internet-facing APIs, message ingestion services, gateways, and systems that process untrusted protobuf messages.
• Upgrade protobufjs to 7.5.6 or later, or 8.0.2 or later, and rebuild all affected deployable artifacts.
• Review application validation logic for protobuf inputs and move security-sensitive checks to operate on decoded, canonical strings rather than raw bytes.
• Add tests for overlong UTF-8 encodings in protobuf string fields to prevent regression.
• Monitor for anomalous protobuf payloads containing overlong UTF-8 byte sequences, especially where validation failures, policy denials, or parsing errors are logged.
• Because this vulnerability is not currently in KEV and EPSS is low, treat it as a dependency hygiene and input-validation hardening priority unless the affected service accepts untrusted protobuf data and uses byte-level filtering, in which case prioritize remediation higher.