Threats Tagged 'gcve'

Active exploitation of three critical vulnerabilities in JFrog Artifactory has been identified, with attackers chaining CVE-2026-42016, CVE-2026-42018, and CVE-2026-82329 to bypass authentication and gain administrative control. CVE-2026-42018 exposes internal anonymous-user tokens, CVE-2026-42016 enables privilege escalation through insufficient token validation, and CVE-2026-82329 allows unauthenticated access to administrative privileges. Post-exploitation activities include creating persistent administrator accounts, deploying malicious Groovy plugins for code execution, and installing Rust-based backdoors. Exploitation was observed between August 15 and September 8, 2026, affecting multiple organizations. Data indicates 67-69% of organizations running Artifactory had vulnerable instances at initial publication, with slow patching velocity for lower-severity CVEs despite active exploitation across environments.

Found through variant analysis based on `CVE-2026-41643` ## Summary GoBGP accepts a zero-length AS_PATH during UPDATE decoding and later panics while validating that attribute for a confederation eBGP peer. The vulnerable path is in the BGP UPDATE validator: a malformed UPDATE that should be rejected as a malformed AS_PATH instead reaches an unchecked `p.Value[0]` access, allowing a configured confederation eBGP peer to trigger a denial of service. ## Affected - Project: gobgp - Repo: https://github.com/osrg/gobgp - Pinned ref: c24629411ba49f160d9dc09126f418218127e016 ## Root cause An established peer's receive path reads BGP bytes from the network connection in `pkg/server/fsm.go:1267`, parses UPDATE bodies through the BGP message decoder, and validates decoded UPDATEs with peer state at `pkg/server/fsm.go:1849`. The UPDATE decoder walks the path-attribute list in `pkg/packet/bgp/bgp.go:15773` and selects the concrete attribute parser from the attacker-controlled attribute type at `pkg/packet/bgp/bgp.go:15855`. For AS_PATH, `PathAttributeAsPath.DecodeFromBytes` returns nil when the decoded attribute length is zero (`pkg/packet/bgp/bgp.go:11533`, `pkg/packet/bgp/bgp.go:11538`), leaving `p.Value` empty rather than reporting a malformed attribute. Validation then dispatches each decoded attribute through `ValidateAttribute` (`pkg/packet/bgp/validate.go:34`); in the confederation eBGP branch, `pkg/packet/bgp/validate.go:162` indexes `p.Value[0]` before checking that any AS_PATH segment was decoded. The eBGP and confederation guards are normal peer-state gates: `pkg/config/oc/util.go:127` defines eBGP as peer AS differing from local AS, `pkg/config/oc/util.go:116` checks confederation membership, and `pkg/server/fsm.go:740` and `pkg/server/fsm.go:741` copy those results into the FSM state used by the validator. ## Reproduction [INT-bgp-gobgp-confed-empty-aspath-panic.zip](https://github.com/user-attachments/files/28203698/INT-bgp-gobgp-confed-empty-aspath-panic.zip) ```bash bash ./poc/run.sh ``` ```text TRIGGERED: confed empty AS_PATH validation panic: runtime error: index out of range ``` The `TRIGGERED` line is the recovered panic fingerprint from the confederation eBGP validation path after a zero-length AS_PATH has decoded successfully. A build failure or any output without that fingerprint would not demonstrate this bug, because the signal is tied to the unchecked AS_PATH segment access. ## Impact A remote unauthenticated peer that is configured as a confederation eBGP neighbor can establish a BGP session and send a single malformed UPDATE containing a syntactically valid AS_PATH attribute header with zero value length. Because the decode path does not turn that empty AS_PATH into a `MessageError`, normal malformed-attribute handling is bypassed and validation panics before GoBGP can return a BGP NOTIFICATION. The demonstrated effect is denial of service for the receive goroutine and peer session, with potential process termination if the panic is not recovered by the runtime path; no memory corruption, data disclosure, authentication bypass, or code execution is claimed. ## Suggested fix ```001-fix.diff diff --git a/pkg/packet/bgp/validate.go b/pkg/packet/bgp/validate.go index 2237afb..f07f4fa 100644 --- a/pkg/packet/bgp/validate.go +++ b/pkg/packet/bgp/validate.go @@ -159,6 +159,9 @@ func ValidateAttribute(a PathAttributeInterface, rfs map[Family]BGPAddPathMode, case *PathAttributeAsPath: if isEBGP { if isConfed { + if len(p.Value) == 0 { + return false, NewMessageError(eCode, eSubCodeMalformedAspath, nil, "empty AS_PATH for confederation eBGP") + } if segType := p.Value[0].GetType(); segType != BGP_ASPATH_ATTR_TYPE_CONFED_SEQ { return false, NewMessageError(eCode, eSubCodeMalformedAspath, nil, fmt.Sprintf("segment type is not confederation seq (%d)", segType)) } ``` ## Resources - https://github.com/osrg/gobgp/blob/c24629411ba49f160d9dc09126f418218127e016/pkg/packet/bgp/bgp.go#L11533-L11540 - https://github.com/osrg/gobgp/blob/c24629411ba49f160d9dc09126f418218127e016/pkg/packet/bgp/validate.go#L159-L164

### Summary GoBGP contains a BGP OPEN capability parsing issue where several concrete capability decoders may parse data from the full remaining capability buffer instead of the slice bounded by the declared capability length, `CapLen`. A malformed BGP OPEN message can cause bytes from a following capability to be interpreted as part of the current capability. The most security-relevant case is the 4-octet AS capability, where a capability with `CapLen == 0` may cause the parser to read bytes from the following capability as the 4-octet AS value. This parsed value may later affect peer AS validation during BGP session establishment. ### Details The issue is in the BGP OPEN capability parser under: - `pkg/packet/bgp/bgp.go` - `pkg/packet/bgp/validate.go` - The BGP OPEN optional parameter capability format includes a capability code, a capability length field, and a capability value. Each concrete capability decoder should only parse bytes inside the declared capability value boundary. In affected versions, the generic capability parser records the declared `CapLen`, but several concrete capability decoders continue parsing from the full remaining capability buffer after advancing past the two-byte capability header. Conceptually, the vulnerable pattern is: ```go data = data[2:] // decoder reads from data without first limiting it to CapLen ### PoC The following parser-level proof of concept demonstrates the issue without requiring a full BGP session or a running `bgpd` instance. The malformed capability uses: - Capability Code: `65` (`BGP_CAP_FOUR_OCTET_AS_NUMBER`) - Declared `CapLen`: `0` - Four following bytes: `00 00 fd e8` Although the capability declares an empty value, affected versions parse the following four bytes as the 4-octet AS value `65000`. ### Impact A remote peer that can send a malformed BGP OPEN message to a GoBGP instance may cause capability values to be parsed from outside their declared `CapLen` boundaries. In the 4-octet AS capability case, this may affect: - peer AS validation; - capability negotiation; - interpretation of malformed OPEN messages; - acceptance or rejection decisions during BGP session establishment. This issue does not appear to be arbitrary memory corruption, remote code execution, or information disclosure. It is a protocol parser boundary validation issue that can affect BGP OPEN validation semantics.

CVE-2026-45751 is a use-after-free vulnerability in Suricata, a network intrusion detection and prevention system. The flaw occurs in the inspection-buffer helper when a chained transform causes the backing buffer to be reallocated, leaving an inspection pointer referencing freed memory. This issue is triggered during specific network traffic processing and requires a particular, though not malicious, rule involving the chaining of the 'dotprefix' transform. Versions prior to 7.0.16 and versions from 8.0.0 up to but not including 8.0.5 are affected. Fixed in versions 7.0.16 and 8.0.5. The vulnerability has a CVSS score of 5.9 (medium severity) and does not impact confidentiality or integrity but can cause availability issues.

Traefik contains a medium severity vulnerability (CVE-2026-88011) involving header aliasing that allows identity spoofing via dot-form header names. Traefik treats headers with dashes, underscores, and dots as distinct, but some backends collapse these into the same variable, enabling an attacker to bypass ForwardAuth identity assertions. This affects Traefik v1.x, v2 up to 2.11.55, and v3 from 3.0.0 to 3.7.11. The vulnerability allows a permitted lower-privilege client to impersonate another user or role. Patches are available in v2.11.56 and v3.7.12, which introduce the aliasHeadersStrategy option to mitigate the issue.

A medium severity vulnerability in Traefik affects HTTP/3 entry points where the respondingTimeouts.readTimeout setting is not applied. This setting, which limits the time to read the entire request including its body, works for HTTP/1.1 and HTTP/2 but is ineffective for HTTP/3 due to architectural differences. As a result, an unauthenticated client can keep a request open indefinitely by trickling the request body slowly, consuming upstream connections and potentially exhausting backend connection pools. The issue affects Traefik versions from 2.8.2 up to but not including 2.11.56, and from 3.0.0 up to but not including 3.7.12. Patches are available in versions 2.11.56 and 3.7.12.

An XSS vulnerability (CVE-2026-88060) exists in @angular/platform-server during server-side rendering (SSR) HTML serialization when untrusted input is rendered inside <template> elements nested within fallback raw-content elements like <noscript>. The vulnerability arises because the serializer fails to escape closing tags such as </noscript> inside template content due to incomplete ancestor traversal across DocumentFragment boundaries. This causes premature termination of fallback containers and execution of injected markup in browsers. The issue affects multiple Angular platform-server versions and bypasses Angular's default text interpolation safety guarantees during SSR. Workarounds include avoiding untrusted input inside such nested templates and fallback containers. A patch is available for this vulnerability.

A vulnerability in @angular/platform-server's Server-Side Rendering (SSR) URL resolution allows attackers to bypass same-origin checks due to a discrepancy in Unicode whitespace handling between WHATWG URL parsing and Angular's URL utilities. This can lead to Server-Side Request Forgery (SSRF) and leakage of sensitive server-side credentials such as Authorization headers. The issue arises because Angular's URL resolution trims Unicode whitespace characters that WHATWG URL parsing does not, causing URLs with leading non-breaking spaces to be misinterpreted and routed to attacker-controlled domains. This affects Angular SSR applications that attach sensitive credentials to requests after performing same-origin validation using WHATWG URL parsing. Workarounds include sanitizing input URLs to remove leading Unicode whitespace before validation and not relying solely on WHATWG URL origin checks when input may be trimmed differently.

A vulnerability in @angular/common's HttpTransferCache allows sensitive authenticated response data to be cached and leaked to unauthorized users when using Server-Side Rendering (SSR) with hydration and a hierarchical HttpClient configuration employing withRequestsMadeViaParent(). This occurs because the child HttpClient marks requests as cacheable before parent interceptors inject authentication headers, causing private data to be cached and potentially served to other users via shared caches. The issue is fixed in versions 22.1.1, 21.2.20, and 20.3.28.

A vulnerability in Angular's @angular/core and @angular/compiler allows sanitization bypass via directive host bindings on certain concrete host elements. This occurs because the Angular compiler incorrectly determines the security context for directive host bindings based on the directive or component selector rather than the actual host element. This flaw can lead to untrusted inputs, such as javascript: URLs, being inserted into DOM attributes without sanitization, enabling Cross-Site Scripting (XSS) attacks. The issue affects multiple Angular versions prior to patched releases. Official patches are available in versions 22.1.0, 21.2.20, and 20.3.28. Users are advised to sanitize inputs explicitly or restrict URL schemes as a workaround.