Vulnerability feed

CVE and vendor PSIRT advisories from 13 sources, last 30 days. Updated hourly, last run Oct 26 08:05 UTC

Critical in the last 24 hours

1601 in 30 days

Newly known exploited

In the last 24 hours, CISA KEV and vendor reports

Sources checked

Every hour, see the list

New in the last 24 hours

181-70% vs 7-day avg of 598

2 critical, 65 high, 73 medium, 31 low

106 advisories match Clear all Export 25 shown as CSV

Expand	Severity	Score	Advisory	Title	Source	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	Oct 23 09:17 UTC
CVE-2026-89320`HmacShaCryptor.Hash` never hashed its input Executive summary A 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 summary The 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 exploited ConfidentialityLow IntegrityHigh AvailabilityNone How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse Foundation Eclipse KeyPont - GOSE Eclipse Foundation gose ThalesGroup gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
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 summary The 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 summary The 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 exploited ConfidentialityNone IntegrityNone AvailabilityLow How it is exploited Attack vector Network Attack complexity High Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
CVE-2026-89318`JweRsaKeyEncryptionDecryptorImpl.Decrypt` passed the JWE's initialization vector to `cipher.AEAD.Open` without checking its length Executive summary A 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 summary The 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 exploited ConfidentialityNone IntegrityNone AvailabilityLow How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
CVE-2026-89317gose parsed the JWS `crit` header into `JwsHeader.Crit` and then never read it Executive summary The 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 summary This 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 exploited ConfidentialityNone IntegrityLow AvailabilityNone How it is exploited Attack vector Network Attack complexity High Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
CVE-2026-89316`LoadPublicKey` resolved an EC key's curve with an unchecked type assertion, `algToOptsMap[alg].(ECDSAOptions)` Executive summary The 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 summary The 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 exploited ConfidentialityNone IntegrityNone AvailabilityLow How it is exploited Attack vector Network Attack complexity High Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse Foundation Eclipse KeyPont - GOSE Eclipse Foundation gose ThalesGroup gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
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 summary The 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 summary The 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 exploited ConfidentialityNone IntegrityNone AvailabilityLow How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
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 summary A 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 summary The 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 exploited ConfidentialityNone IntegrityNone AvailabilityLow How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
CVE-2026-89313`JwksTrustStore.Get` assigned each parsed key to the function's named return value while refreshing the JWKS cache Executive summary A 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 summary This 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 exploited ConfidentialityNone IntegrityLow AvailabilityNone How it is exploited Attack vector Network Attack complexity High Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC 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	Oct 23 09:17 UTC
CVE-2026-89312`AesGcmCryptor.Open` passed a caller-supplied nonce straight to `cipher.AEAD.Open` without checking its length Executive summary A 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 summary The 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 exploited ConfidentialityNone IntegrityNone AvailabilityLow How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None 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 Affects Eclipse Foundation ThalesGroup Eclipse KeyPont Eclipse Foundation Eclipse KeyPont - GOSE ThalesGroup gose Eclipse KeyPont gose NIST National Vulnerability DatabasePublished Oct 23, 2026 09:17 UTC Read the advisory
	High	8.7	CVE-2026-110938	In Eclipse OpenJ9 versions up to 0.63.0, the JITServer component is vulnerable to denial of service due to improper boundary checks during protocol message and reply handling Eclipse Foundation, EclipseEclipse Foundation Eclipse OpenJ9, Eclipse OpenJ9	NVD	Oct 21 09:17 UTC
CVE-2026-110938In Eclipse OpenJ9 versions up to 0.63.0, the JITServer component is vulnerable to denial of service due to improper boundary checks during protocol message and reply handling Executive summary Eclipse OpenJ9 versions up to 0.63.0 have a flaw in the JITServer component that can allow a denial of service. The advisory does not state a severity score, and it does not say whether the vendor has released a fixed version beyond the code changes described in the linked pull requests. Technical summary The flaw is an improper boundary check on protocol messages and reply handling in the JITServer component of Eclipse OpenJ9 up to 0.63.0. A malicious client can send crafted messages with data descriptors whose size, padding, and data offset values misrepresent the payload, causing the server to read past the allocated message buffer or loop infinitely on very large messages. The described fixes add descriptor validation, a 1 GB message size limit, a 256 parameter limit, and a StreamFailure exception on out-of-bounds reads. The advisory does not state a CVSS score, affected version ranges beyond 'up to 0.63.0', a fixed version number, a workaround, or detection guidance. Exploitation 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-openj9/openj9/pull/25011 Impact if exploited ConfidentialityNone IntegrityNone AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Eclipse Foundation Eclipse OpenJ9 Eclipse OpenJ9 NIST National Vulnerability DatabasePublished Oct 21, 2026 09:17 UTC Read the advisory
	High	8.7	CVE-2026-111075	In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset`... Eclipse Foundation, EclipseEclipse Foundation Eclipse OpenJ9, Eclipse OpenJ9, Eclipse JITServer	NVD	Oct 21 08:16 UTC
CVE-2026-111075In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset`... Executive summary The advisory says Eclipse OpenJ9 versions prior to 0.63.0 are affected by a flaw in the JITServer component that lets an attacker-controlled message descriptor cause the server to read out-of-bounds data. The advisory text provided does not state a severity rating, and it does not state a fixed version beyond the 0.63.0 threshold named in the description. Technical summary The flaw is a missing cross-field validation of attacker-controlled _size, _paddingSize, and _dataOffset values in a JITServer message data descriptor, which can make getPayloadSize() return a very large value and cause out-of-bounds reads. The advisory describes a malicious client as the attacker and implies a network-reachable JITServer connection, but a specific attack vector and authentication requirements are not stated. Affected versions are stated as prior to 0.63.0. The commit notes describe fixes that add DataDescriptor::validate(), limit _paddingSize to less than 4, limit _dataOffset to 0 or 4, require _size to be at least _paddingSize plus _dataOffset, cap messages at 256 parameters, and refuse messages larger than 1 GB, but the advisory does not state a workaround, a CVSS score, exploitation status, or detection guidance. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Summarized from github.com/eclipse-openj9/openj9/pull/25009 Impact if exploited ConfidentialityNone IntegrityNone AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Eclipse Foundation Eclipse OpenJ9 Eclipse OpenJ9 Eclipse JITServer NIST National Vulnerability DatabasePublished Oct 21, 2026 08:16 UTC Read the advisory
	High	8.7	CVE-2026-111074	In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component is vulnerable to a pre-authentication remote denial of service Eclipse Foundation, EclipseEclipse Foundation Eclipse OpenJ9, Eclipse OpenJ9	NVD	Oct 21 08:16 UTC
CVE-2026-111074In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component is vulnerable to a pre-authentication remote denial of service Executive summary The advisory says Eclipse OpenJ9 versions prior to 0.63.0 have a flaw in the JITServer component that allows a remote attacker to cause a denial of service without authenticating. The text includes a developer discussion of a fix that makes the server refuse messages larger than 1 GB. The advisory does not state a severity score, so the seriousness beyond denial of service is not stated. Technical summary The advisory describes a pre-authentication remote denial of service in the JITServer component of Eclipse OpenJ9 prior to 0.63.0. The embedded developer text says oversized messages could cause the server to allocate excessive memory and could trigger an infinite loop in MessageBuffer::computeRequiredCapacity() when message size exceeds 2 GB. The fix described is to refuse any message larger than 1 GB, referenced by commit 3ab6df2. The advisory does not state a CVSS score, an exploitation status, or a specific fixed version number beyond the 0.63.0 threshold, and it does not state workarounds or detection guidance. Summaries are generated by AI from the linked advisory text. Confirm versions and fixes at the source. Dropped extracted product not named in the source: Eclipse OpenJ9 JITServer Summarized from github.com/eclipse-openj9/openj9/pull/25008 Impact if exploited ConfidentialityNone IntegrityNone AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Eclipse Foundation Eclipse OpenJ9 Eclipse OpenJ9 NIST National Vulnerability DatabasePublished Oct 21, 2026 08:16 UTC Read the advisory
	High	8.5	CVE-2026-95109	The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating one address — the first byte Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-95109The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating one address — the first byte From the advisory The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating one address — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start. A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on. Impact if exploited ConfidentialityHigh IntegrityHigh AvailabilityHigh How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Medium	6.8	CVE-2026-95108	One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-95108One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one From the advisory One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list. The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning `TX_SUCCESS` — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system. Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. Impact if exploited ConfidentialityNone IntegrityNone AvailabilityHigh How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	High	7.0	CVE-2026-95107	A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate` Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-95107A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate` From the advisory A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result without checking the addition. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block. Impact if exploited ConfidentialityLow IntegrityHigh AvailabilityHigh How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Medium	4.8	CVE-2026-94202	The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's... Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-94202The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's... From the advisory The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built. Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. Impact if exploited ConfidentialityLow IntegrityNone AvailabilityLow How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	High	8.5	CVE-2026-94192	A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with... Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-94192A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with... From the advisory A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation. Impact if exploited ConfidentialityHigh IntegrityHigh AvailabilityHigh How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Medium	6.9	CVE-2026-94024	The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with... Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-94024The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with... From the advisory The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one. A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life. Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`). Impact if exploited ConfidentialityLow IntegrityNone AvailabilityHigh How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Medium	6.9	CVE-2026-94023	A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside... Eclipse FoundationEclipse Foundation Eclipse ThreadX	NVD	Oct 20 16:17 UTC
CVE-2026-94023A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside... From the advisory A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for using an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it. Impact if exploited ConfidentialityNone IntegrityHigh AvailabilityHigh How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required Low User interaction None CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	High	8.8	CVE-2026-94018	The Web add-on's HTTP server dereferences and releases an uninitialized pointer when it detects a `Content-Length` underflow while processing a `PUT` request Eclipse FoundationEclipse Foundation eclipse-threadx/netxduo	NVD	Oct 20 16:17 UTC
CVE-2026-94018The Web add-on's HTTP server dereferences and releases an uninitialized pointer when it detects a `Content-Length` underflow while processing a `PUT` request From the advisory The Web add-on's HTTP server dereferences and releases an uninitialized pointer when it detects a `Content-Length` underflow while processing a `PUT` request. The condition is reachable by an unauthenticated remote client with a single malformed request. Impact if exploited ConfidentialityNone IntegrityLow AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H/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 Affects Eclipse Foundation Eclipse Foundation eclipse-threadx/netxduo NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Critical	9.3	CVE-2026-93475	The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the... Eclipse FoundationEclipse Foundation eclipse-threadx/netxduo	NVD	Oct 20 16:17 UTC
CVE-2026-93475The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the... From the advisory The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the `NX_CRYPTO_MAX_RSA_MODULUS_SIZE` default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification. It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server's chain, and on a server performing client-certificate authentication. Impact if exploited ConfidentialityHigh IntegrityHigh AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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 Affects Eclipse Foundation Eclipse Foundation eclipse-threadx/netxduo NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Medium	6.9	CVE-2026-93003	The Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section Eclipse FoundationEclipse Foundation eclipse-threadx/netxduo	NVD	Oct 20 16:17 UTC
CVE-2026-93003The Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section From the advisory The Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section. A header field name placed in the request body is therefore reported to the server as though it were a header, which lets a client control request framing decisions it should not be able to reach. Impact if exploited ConfidentialityNone IntegrityLow AvailabilityLow How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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 Affects Eclipse Foundation Eclipse Foundation eclipse-threadx/netxduo NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	High	8.7	CVE-2026-92853	The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip Eclipse FoundationEclipse Foundation eclipse-threadx/netxduo	NVD	Oct 20 16:17 UTC
CVE-2026-92853The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip From the advisory The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip. A zero-length Certificate message therefore wraps the unsigned length to `0xFFFFFFFF`, which makes the bounds check that follows vacuous and sends the parser reading past the session packet buffer. The trigger is a four-byte handshake header and requires no cryptographic validity. It is reachable pre-authentication. Impact if exploited ConfidentialityNone IntegrityNone AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Foundation eclipse-threadx/netxduo NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	High	8.7	CVE-2026-92843	A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap... Eclipse FoundationEclipse Foundation eclipse-threadx/netxduo	NVD	Oct 20 16:17 UTC
CVE-2026-92843A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap... From the advisory A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap out-of-bounds read in any peer that processes a remote Certificate message. It is reachable pre-authentication, during the normal handshake, before certificate verification completes. Impact if exploited ConfidentialityNone IntegrityNone AvailabilityHigh How it is exploited Attack vector Network Attack complexity Low Attack requirements None Privileges required None User interaction None CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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 Affects Eclipse Foundation Eclipse Foundation eclipse-threadx/netxduo NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory
	Medium	4.6	CVE-2026-91057	`_gx_multi_line_text_view_display_info_get()` reads one byte past the end of the application's text buffer when the string it is given ends with a carriage return (`\r`) Eclipse FoundationEclipse Foundation Eclipse ThreadX - GUIX	NVD	Oct 20 16:17 UTC
CVE-2026-91057`_gx_multi_line_text_view_display_info_get()` reads one byte past the end of the application's text buffer when the string it is given ends with a carriage return (`\r`) From the advisory `_gx_multi_line_text_view_display_info_get()` reads one byte past the end of the application's text buffer when the string it is given ends with a carriage return (`\r`). The over-read can also cause callers to advance their index past the end of the string, producing a second over-read in `_gx_multi_line_text_view_string_total_rows_compute()` and a row of text that is not in the source. Impact if exploited ConfidentialityLow IntegrityNone AvailabilityLow How it is exploited Attack vector Local Attack complexity Low Attack requirements None Privileges required None User interaction Active CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:L/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 Affects Eclipse Foundation Eclipse Foundation Eclipse ThreadX - GUIX NIST National Vulnerability DatabasePublished Oct 20, 2026 16:17 UTC Read the advisory

Example	Finds
	Every word appears somewhere: title, summaries, IDs, vendor, or product
	An exact phrase
	One vendor. product: for a product, vp: for either
	Commas mean any of them, in every field
	Severity: critical, high, medium, low, or unknown
	CVSS score, with >, >=, <, or <=
	A score range
	Known exploited. is:kev works too, and kev:no leaves them out
	One source, by name
	Confidentiality impact: high, low, none, or any (low or high)
	Integrity and availability work the same way
	An advisory or CVE ID, or part of one
	A minus sign leaves out whatever the term matches

Vulnerability feed

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

Executive summary

Technical summary

Impact if exploited

How it is exploited

Affects

From the advisory

Impact if exploited

How it is exploited

Affects

From the advisory

Impact if exploited

How it is exploited

Affects

From the advisory

Impact if exploited

How it is exploited

Affects

From the advisory

Impact if exploited

How it is exploited

Affects

From the advisory

Impact if exploited

How it is exploited