Vulnerability feed
CVE and vendor PSIRT advisories from 13 sources, last 30 days. Updated hourly, last run
| Expand | Severity |
Score |
Advisory |
Title |
Source |
Flags |
Published |
|---|---|---|---|---|---|---|---|
| High | 8.8 | CVE-2026-89320 |
`HmacShaCryptor.Hash` never hashed its input
Eclipse Foundation, ThalesGroupEclipse Foundation Eclipse KeyPont - GOSE, Eclipse Foundation gose, ThalesGroup gose
|
NVD | |||
|
CVE-2026-89320`HmacShaCryptor.Hash` never hashed its input
Executive summaryA flaw in the gose Go library's HMAC routine means that AES-CBC-HMAC encrypted JWE messages lose their integrity protection, so an attacker who has seen one valid message can alter ciphertext and still pass verification. The advisory rates the issue High (CVSS 3.1 vector given as AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N, with a score of 8.2 shown). The fix requires consumers to move to a new module path, eclipse-keypont/gose at v1.0.0-rc1 or later, because the original module path has no patched release. Technical summaryThe weakness is CWE-354, improper validation of an integrity check value, in HmacShaCryptor.Hash, which calls hash.Sum(input) without first writing the input, so it always returns HMAC_K("") regardless of input. An attacker on the network who has observed one legitimate AES-CBC-HMAC JWE can reuse its tag on forged ciphertext, headers, and IVs, and the advisory describes CBC malleability and a panic on non-block-aligned ciphertext as consequences. Affected versions are github.com/ThalesGroup/gose >= v0.9.0 and <= v0.13.0-rc1, with no patched release under that path. The fixed version is github.com/eclipse-keypont/gose >= v1.0.0-rc1, reached by changing the module path, and the fix commit is 97f9348. Workarounds are not stated for the affected releases beyond avoiding the AES-CBC-HMAC path and using AEAD/GCM instead. Data protected by affected releases should be treated as unauthenticated and re-encrypted under a patched version. Detection guidance is not stated in the advisory. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-h6w5-722x-2h3m Impact if exploitedConfidentialityLow IntegrityHigh AvailabilityNone
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse Foundation Eclipse KeyPont - GOSEEclipse Foundation goseThalesGroup gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-89319 |
`JweDirectDecryptorBlock.Decrypt` read a 64-bit plaintext length from the `_thales_aad` protected-header field and used it without any validation
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89319`JweDirectDecryptorBlock.Decrypt` read a 64-bit plaintext length from the `_thales_aad` protected-header field and used it without any validation
Executive summaryThe advisory says a flaw in the Go JOSE library gose, in its AES-CBC-HMAC direct decryption path, lets a remote sender crash the decrypting process or force a very large memory allocation. It is rated Low in the NVD-style header and Low in the CVSS summary, with availability impact only. The recommended fix is to move to the eclipse-keypont module path and use version v1.0.0-rc4, because the ThalesGroup path has no patched release. Technical summaryThe flaw is an improper validation of an array index (CWE-129) in JweDirectDecryptorBlock.Decrypt, which reads a 64-bit plaintext length from the attacker-controlled _thales_aad protected-header field without checking that the field exists, is at least 8 bytes, or is within the decrypted block length. The advisory says a related HMAC defect (GHSA-h6w5-722x-2h3m) lets an attacker reuse a constant tag, so the integrity gate can be passed without the MAC key, though it also notes the CVSS attack complexity is rated High. Affected versions are stated as >= 0.9.0, <= 0.13.0-rc1 for github.com/ThalesGroup/gose, which has no patched release. For github.com/eclipse-keypont/gose the advisory states the fix is in v1.0.0-rc1 and recommends v1.0.0-rc4. Workarounds are stated as none within affected releases, with avoiding the CBC-HMAC path (NewJweDirectDecryptorBlock) in favour of the GCM path suggested as a mitigation for users who cannot migrate. No CVSS vector beyond the base metrics shown, no exploitation-in-the-wild status, and no detection guidance are stated in the advisory. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-4gj8-hg2r-gw6q Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.9 | CVE-2026-89318 |
`JweRsaKeyEncryptionDecryptorImpl.Decrypt` passed the JWE's initialization vector to `cipher.AEAD.Open` without checking its length
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89318`JweRsaKeyEncryptionDecryptorImpl.Decrypt` passed the JWE's initialization vector to `cipher.AEAD.Open` without checking its length
Executive summaryA flaw in the Go JOSE library gose lets anyone holding a recipient's public key send a crafted encrypted message that crashes the process or request handling the decryption. The advisory rates it Moderate, with availability impact only and no confidentiality or integrity loss. The recommended fix is to upgrade to github.com/eclipse-keypont/gose v1.0.0-rc4 or later, and users of the older ThalesGroup module path must change the module path, since no patched version exists under that path. Technical summaryThe issue is CWE-248, an uncaught exception: JweRsaKeyEncryptionDecryptorImpl.Decrypt passes the JWE initialization vector to cipher.AEAD.Open without checking its length, and Go's standard library GCM panics on any nonce that is not 12 bytes. The attack is network-reachable and requires no secret, only the recipient's RSA public key, kid, and OAEP hash, which the advisory describes as public in normal JOSE deployments. Affected versions are stated as github.com/ThalesGroup/gose >= 0.8.0, <= 0.13.0-rc1 (no patched version under that path) and github.com/eclipse-keypont/gose < 1.0.0-rc4, with the fix in >= 1.0.0-rc4. The stated workaround is to validate that the decoded IV is 12 bytes before calling Decrypt, though the advisory notes this does not fix the underlying defect. The advisory states that no detection guidance is given and that the CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L; the attached analysis is AI-generated and unverified by a maintainer. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-265w-83cm-777q Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-89317 |
gose parsed the JWS `crit` header into `JwsHeader.Crit` and then never read it
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89317gose parsed the JWS `crit` header into `JwsHeader.Crit` and then never read it
Executive summaryThe advisory says the gose JWT/JWS verification library ignores the signed crit header, so tokens that carry issuer-mandated critical extensions it does not support are accepted instead of rejected. It rates the issue Low, noting it is not remotely exploitable by an unauthenticated party and requires a validly signed token replayed into a gose-backed verifier. The fix is to upgrade to eclipse-keypont/gose v1.0.0-rc4 or later, and users still on the ThalesGroup module path must change the module path. Technical summaryThis is an improper verification of a signed header parameter (CWE-347) in JwtVerifierImpl.Verify, which never reads the JWS crit header required by RFC 7515 section 4.1.11. The attack requires a token validly signed by a trusted issuer, replayed in a context where gose is the verifier; the signature covers crit, so it cannot be forged into an unsigned token. Affected versions are stated as github.com/ThalesGroup/gose >= 0.7.3, <= 0.13.0-rc1 (no patched version given on that path) and github.com/eclipse-keypont/gose < 1.0.0-rc4, fixed in >= 1.0.0-rc4. The fix rejects any non-empty crit in jose.Jwt.Verify, and the advisory gives a workaround of rejecting tokens whose crit member is present and non-empty before calling Verify. The advisory does not state exploitation in the wild, and it notes a related unfixed gap in JweProtectedHeader lacking a Crit field. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-445r-fpvv-hgwc Impact if exploitedConfidentialityNone IntegrityLow AvailabilityNone
How it is exploited
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-89316 |
`LoadPublicKey` resolved an EC key's curve with an unchecked type assertion, `algToOptsMap[alg].(*ECDSAOptions)`
Eclipse Foundation, ThalesGroupEclipse Foundation Eclipse KeyPont - GOSE, Eclipse Foundation gose, ThalesGroup gose
|
NVD | |||
|
CVE-2026-89316`LoadPublicKey` resolved an EC key's curve with an unchecked type assertion, `algToOptsMap[alg].(*ECDSAOptions)`
Executive summaryThe advisory says that the gose Go library for JOSE and JWK handling can crash when LoadPublicKey receives an EC key whose declared algorithm is not an EC algorithm. The advisory rates this Low severity, a denial-of-service issue that depends on the calling application forwarding untrusted key documents to the function. The vendor recommends upgrading to github.com/eclipse-keypont/gose v1.0.0-rc4 or later, and it notes that consumers on the old ThalesGroup module path must change the module path, not just the version. Technical summaryThe flaw is an unchecked type assertion of algToOptsMap[alg] to *ECDSAOptions in LoadPublicKey, classified as CWE-248 (Uncaught Exception), which panics when a JWK with kty EC carries a non-EC alg such as RS256, PS256, or RSA-OAEP. The attack vector is network with high attack complexity, and the precondition is that the calling application passes an externally supplied JWK document directly to LoadPublicKey. Affected versions are github.com/ThalesGroup/gose >= 0.7.3, <= 0.13.0-rc1 (patched versions: None stated) and github.com/eclipse-keypont/gose < 1.0.0-rc4, fixed in >= 1.0.0-rc4. The advisory gives a CVSS v3.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L and says the availability impact is low. No workaround beyond not passing untrusted JWKs to LoadPublicKey or validating that kty and alg agree is stated as a mitigation, and no detection guidance is given. Whether exploitation has occurred in the wild is not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-fv39-8484-f4wr Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse Foundation Eclipse KeyPont - GOSEEclipse Foundation goseThalesGroup gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.9 | CVE-2026-89315 |
`JwtClaims.MarshalJSON` built a Go struct at runtime with `reflect.StructOf`, synthesising a field named `"A" + claimName` for each untyped claim
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89315`JwtClaims.MarshalJSON` built a Go struct at runtime with `reflect.StructOf`, synthesising a field named `"A" + claimName` for each untyped claim
Executive summaryThe advisory says that the gose Go library for JSON Web Tokens can crash when it marshals verified claims that contain common custom claim names, such as URL-namespaced names used by many identity providers. The advisory rates the issue Moderate and states a CVSS v3.1 score of 5.3, with availability impact only. The fix is to move to the Eclipse Keypont module github.com/eclipse-keypont/gose version v1.0.0-rc4 or later, because the ThalesGroup path is still vulnerable and go get -u will not fix it. Technical summaryThe flaw is an uncaught panic (CWE-248) in JwtClaims.MarshalJSON, which builds a struct with reflect.StructOf using field names derived from untyped claim keys. Claim names containing characters such as hyphen, dot, colon, slash, space, #, @, or URL forms, and the name utomaticJwtClaims (which collides with an embedded field), cause the panic. An attacker needs a token that passes signature verification against a trusted key, and the caller must then JSON-marshal the returned claims; the advisory notes this is a caller behaviour. The affected range is listed as >= 0.7.3 and <= 0.13.0-rc1 for github.com/ThalesGroup/gose and less than 1.0.0-rc4 for github.com/eclipse-keypont/gose, with the patched version given as >= 1.0.0-rc4. The fix commit is listed as be2277b, merged as 692c25c. Workarounds are stated as avoiding json.Marshal on the returned claims or copying UntypedClaims into a separate map first. The advisory does not state whether exploitation has been seen in the wild, and it does not state a detection method beyond the reproducer. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-hwm6-rwv6-xgq8 Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.9 | CVE-2026-89314 |
`jwkFields.CheckConsistency` detected duplicate `key_ops` entries with a pairwise nested loop, making validation cost grow with the **square** of the entry count
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89314`jwkFields.CheckConsistency` detected duplicate `key_ops` entries with a pairwise nested loop, making validation cost grow with the **square** of the entry count
Executive summaryA denial-of-service flaw affects the gose Go library for JSON Web Keys, where a crafted key set under 1 MB can keep one CPU core busy for about 15 seconds. The advisory rates it Moderate and states the attacker must control the key set endpoint, such as a compromised or malicious identity provider. The recommended fix is to upgrade to eclipse-keypont/gose v1.0.0-rc4 or later, and to change the module path if still using the ThalesGroup path because that path has no fix. Technical summaryThe flaw is an algorithmic complexity issue (CWE-407) in jwkFields.CheckConsistency, which checks key_ops entries for duplicates with a nested loop, giving quadratic time. An attacker who controls the JWKS body (for example, a malicious or compromised endpoint or a MITM on a configured JWKS URL) can send many unique key_ops values; the advisory reports a sub-1 MB body costing roughly 15 seconds of CPU. The advisory states the affected versions as >= 0.7.3, <= 0.13.0-rc1 for github.com/ThalesGroup/gose (no patched version stated for that path) and < 1.0.0-rc4 for github.com/eclipse-keypont/gose, with the patched version stated as >= 1.0.0-rc4. The fix adds a 64-entry cap and a set-based duplicate check, and the release wraps the JWKS HTTP body in a 1 MiB limit. Workarounds are to fetch JWKS only from trusted pinned endpoints and to limit response body size, with the advisory noting a size limit alone is partial. The advisory does not state exploitation in the wild, and the CVSS v3.1 vector given is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-r56w-f43c-828p Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.3 | CVE-2026-89313 |
`JwksTrustStore.Get` assigned each parsed key to the function's **named return value** while refreshing the JWKS cache
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89313`JwksTrustStore.Get` assigned each parsed key to the function's **named return value** while refreshing the JWKS cache
Executive summaryA flaw in the Go library gose (published under Eclipse KeyPont and ThalesGroup paths) causes its JWKS trust store to return a wrong signing key, instead of no key, when a token names a key ID that is absent from the key set. The advisory rates it Low, states it is not an authentication bypass, and says the fix is to upgrade to github.com/eclipse-keypont/gose v1.0.0-rc4 or later, with consumers on the ThalesGroup module path needing to change the module path because that path has no patched version. Technical summaryThis is a logic error in JwksTrustStore.Get: a named return value is overwritten inside a key-loading loop and a naked return then hands back the last parsed key with err set to nil when the requested kid is not found. The trigger requires an issuer on the operator's allowlist, a non-empty JWKS, and a token whose kid header is absent from that set, and the advisory says an unauthenticated remote party can supply these. The advisory states that signature verification in JwtVerifierImpl.Verify still gates acceptance, so a token signed by an unrelated key is still rejected. Affected versions are stated as >= 0.7.5 and <= 0.13.0-rc1 for github.com/ThalesGroup/gose, and < 1.0.0-rc4 for github.com/eclipse-keypont/gose, with the fix in 1.0.0-rc4 (commit 692c25c); the advisory states no patched version exists for the ThalesGroup path. Workaround stated: callers should check that the returned key's Kid() matches the requested kid and treat a mismatch as not found. The advisory does not state any detection guidance. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-v7r8-g6h9-99vv Impact if exploitedConfidentialityNone IntegrityLow AvailabilityNone
How it is exploited
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||
| Medium | 6.9 | CVE-2026-89312 |
`AesGcmCryptor.Open` passed a caller-supplied nonce straight to `cipher.AEAD.Open` without checking its length
Eclipse Foundation, ThalesGroup, Eclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSE, ThalesGroup gose, Eclipse KeyPont gose
|
NVD | |||
|
CVE-2026-89312`AesGcmCryptor.Open` passed a caller-supplied nonce straight to `cipher.AEAD.Open` without checking its length
Executive summaryA flaw in the Go library gose lets a remote party crash a decrypting process by submitting a crafted JWE with a wrong-sized initialization vector. The advisory rates it Moderate, with availability impact only, and says the process crash depends on whether the calling application recovers panics. The vendor recommends upgrading the eclipse-keypont/gose module to v1.0.0-rc4 or later, and consumers on the ThalesGroup module path must change the module path as well. Technical summaryThe defect is an uncaught panic (CWE-248) in AesGcmCryptor.Open, which passes the attacker-supplied nonce to cipher.AEAD.Open without the length check that the Seal method performs, so a nonce not equal to 12 bytes causes the Go standard library to panic. The attack is network reachable with no privileges or user interaction, and requires only a kid present in the decryptor's keystore, which the advisory says is typically public. The advisory states that confidentiality and integrity are unaffected. Affected versions are >= 0.7.3, <= 0.13.0-rc1 for github.com/ThalesGroup/gose and < 1.0.0-rc4 for github.com/eclipse-keypont/gose; the fixed version is v1.0.0-rc4 for the eclipse-keypont path, and the ThalesGroup path has no patched version. The advisory's workaround is to validate that the decoded IV is 12 bytes for AES-GCM algorithms before calling gose, and it notes that recovering panics at the request boundary limits impact without fixing the defect. Detection guidance beyond the reproducer is not stated. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-keypont/gose/securit…/GHSA-xx6h-2jgg-93m2 Impact if exploitedConfidentialityNone IntegrityNone AvailabilityLow
How it is exploited
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X AffectsEclipse FoundationThalesGroupEclipse KeyPontEclipse Foundation Eclipse KeyPont - GOSEThalesGroup goseEclipse KeyPont gose
NIST National Vulnerability DatabasePublished
Read the advisory
|
|||||||