Withdrawn by the publisher.

Affected: CleanStart: dex

Multiple security vulnerabilities affect the dex package. These issues are resolved in later releases. See references for individual vulnerability details.

goxmlsig provides XML Digital Signatures implemented in Go. Prior to version 1.6.0, 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. goxmlsig version 1.6.0 contains a patch.

Affected: Go: github.com/russellhaering/goxmldsig

### 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.

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

velociraptor-0.7.0.4.git185.a5708584-2.1 on GA media

lodash: prototype pollution in _.unset and _.omit functions golang: archive/tar: Unbounded allocation when parsing GNU sparse map golang: net/url: Memory exhaustion in query parameter parsing in net/url @remix-run/router: react-router: React Router vulnerable to XSS via Open Redirects axios: Axios affected by Denial of Service via __proto__ Key in mergeConfig immutable-js: Immutable.js: Arbitrary code execution via Prototype Pollution github.com/buger/jsonparser: github.com/buger/jsonparser: Denial of Service via malformed JSON input google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation github.com/russellhaering/goxmldsig: goxmlsig: Integrity bypass due to incorrect XML Digital Signature validation via loop variable capture issue axios: Axios: Remote Code Execution via Prototype Pollution escalation