CVE-2026-101915 in grpc-js
Summary
by MITRE • 09/28/2026
@grpc/grpc-js implements the core functionality of gRPC purely in JavaScript, without a C++ addon. Prior to 1.13.6 and 1.14.5, when an application method handler throws an uncaught error, the server includes its error message in the status message sent to the client. The thrown error message is transmitted to the client, causing sensitive information disclosure when the message contains sensitive data. This issue is fixed in versions 1.13.6 and 1.14.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified within @grpc/grpc-js prior to versions 1.13.6 and 1.14.5 represents a critical information disclosure flaw rooted in the framework's error handling mechanism for server-side application methods. As a pure JavaScript implementation of gRPC, this library manages remote procedure calls without relying on native C++ addons, which influences how exceptions are propagated and serialized during communication between client and server components. The core technical defect occurs when an uncaught exception is thrown within an application method handler on the server side. Instead of sanitizing or masking the error details before transmission, the framework directly includes the raw error message from the stack trace in the gRPC status message returned to the requesting client. This behavior bypasses standard security practices that dictate internal implementation details should never be exposed to external parties over a network interface.
From an operational perspective, this flaw allows remote attackers or malicious clients to extract sensitive information about the server's internal state, codebase structure, and potentially underlying infrastructure configurations. If the thrown error message contains database query strings, file paths, authentication token failures, or other proprietary logic details, these are transmitted in plaintext over the network connection. This exposure facilitates further reconnaissance efforts, enabling attackers to refine subsequent attacks such as SQL injection, path traversal, or privilege escalation by understanding exactly where and how the application fails. The impact is particularly severe in microservices architectures where gRPC is commonly used for inter-service communication, as it undermines the principle of least privilege and confidentiality required between service boundaries.
This vulnerability aligns with CWE-209, which describes the generation of error messages that contain sensitive information, and CWE-754, related to improper checking of unusual or exceptional conditions leading to a security-relevant state. In terms of offensive cybersecurity frameworks, this flaw supports the ATT&CK technique T1592.003, specifically Gather Victim Host Information via OS Discovery, as it allows an attacker to gather detailed environmental data through error responses rather than direct system queries. The lack of input validation and output encoding in the exception handling path is a classic example of insecure default configurations that prioritize developer convenience over security during debugging phases but remain active in production environments if not explicitly mitigated by developers.
To mitigate this vulnerability, organizations must upgrade to @grpc/grpc-js version 1.13.6 or later, where the framework has been patched to prevent the direct transmission of unhandled exception messages to clients. In addition to upgrading dependencies, application-level defenses should be implemented to ensure that all server-side errors are caught and wrapped in generic, non-descriptive error responses before being serialized for network transmission. Developers should utilize global error handlers or middleware layers to intercept exceptions from method handlers, log the detailed stack traces internally for debugging purposes, and return standardized HTTP-like status codes with minimal message content to the client. This dual approach of patching the underlying library and enforcing strict output sanitization at the application layer ensures that sensitive internal states remain concealed even if unhandled errors occur during runtime operations.