Most recent entries from all

Withdrawn: CLEANSTART-2026-AG91746 — Security fixes for CVE-2026-25680, CVE-2026-25681, CVE-2026-26958, CVE-2026-27145, CVE-2026-29181, CVE-2026-32952, CVE-…

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.

EUVD-2026-365494

fkie_cve-2026-33487

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.

GHSA-479m-364c-43vc — validateSignature Loop Variable Capture Signature Bypass in goxmldsig

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…

openSUSE-SU-2026:11126-1 — velociraptor-0.7.0.4.git185.a5708584-2.1 on GA media

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

RHSA-2026:13548 — Red Hat Security Advisory: Red Hat Advanced Cluster Management for Kubernetes v2.15.2 security update

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