Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When server credentials are created with the requireClientCertificate option set to false, getAuthContext does not distinguish between authorized and unauthorized certificates in its return value. This can create improper authentication vulnerabilities for @grpc/grpc-js users who use the result of getAuthContext for authentication. In particular, @grpc/grpc-js-xds can both set the requireClientCertificate option to false and use the return value of getAuthContext for RBAC authentication in some configurations. Patches This vulenrability is fixed in 1.13.6 and 1.14.5. Workarounds @grpc/grpc-js users using getAuthContext this way can avoid this problem by setting requireClientCertificate to true. @grpc/grpc-js-xds users using RBAC can avoid this by setting the requireclientcertificate field to true in the DownstreamTlsContext in the xDS configuration.
Recommended action: Upgrade to 1.14.5 or 1.13.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If an application method handler crashes, the error message is included in the status message sent to the client. This can leak to the client any sensitive data that may be included in the error message. This impacts anyone using @grpc/grpc-js to run servers. Patches This vulnerability is fixed in 1.13.6 and 1.14.5. Workarounds This can be avoided by using a top-level error handler in method handlers to strip out sensitive error information.
Recommended action: Upgrade to 1.14.5 or 1.13.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.13.51.14.41.12.71.9.161.10.121.11.4· Vendor fix available
Issue
Impact An invalid incoming HTTP/2 stream initiation can cause a server process to crash. This affects all servers created using @grpc/grpc-js. Patches The following version have fixes for this vulnerability: - 1.9.16 - 1.10.12 - 1.11.4 - 1.12.7 - 1.13.5 - 1.14.4 Workarounds There is no workaround.
Recommended action: Upgrade to 1.14.4, 1.13.5, 1.12.7 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.13.51.14.41.12.71.9.161.10.121.11.4· Vendor fix available
Issue
Impact An invalid incoming compressed message can cause a client or server process to crash. This affects all clients and servers that use @grpc/grpc-js Patches The following version have fixes for this vulnerability: - 1.9.16 - 1.10.12 - 1.11.4 - 1.12.7 - 1.13.5 - 1.14.4 Workarounds There is no workaround.
Recommended action: Upgrade to 1.14.4, 1.13.5, 1.12.7 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There are two separate code paths in which memory can be allocated per message in excess of the grpc.maxreceivemessagelength channel option: 1. If an incoming message has a size on the wire greater than the configured limit, the entire message is buffered before it is discarded. 2. If an incoming message has a size within the limit on the wire but decompresses to a size greater than the limit, the entire message is decompressed into memory, and on the server is not discarded. Patches This has been patched in versions 1.10.9, 1.9.15, and 1.8.22
Recommended action: Upgrade to 1.10.9, 1.9.15 or 1.8.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
"The package grpc before 1.24.4 and the package @grpc/grpc-js before 1.1.8 are vulnerable to Prototype Pollution via loadPackageDefinition."
Recommended action: Upgrade to 1.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.