Eclipse Californium
Approved changes feed: RSS · Atom
cpe:2.3:a:the_eclipse_foundation:eclipse_californium:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | The Eclipse Foundation (bb2d55d2-5306-5bc8-beb2-981f5d5392e4) |
|---|---|
| Product | Eclipse Californium (d8a741c7-1583-5338-ba43-5d82b992559e) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2022-2576 |
vulnerable | 2026-06-03 14:47:06.709589 |
Details available
In Eclipse Californium version 2.0.0 to 2.7.2 and 3.0.0-3.5.0 a DTLS resumption handshake falls back to a DTLS full handshake on a parameter mismatch without using a HelloVerifyRequest. Especially, if used with certificate based cipher suites, that results in message amplification (DDoS other peers) and high CPU load (DoS own peer). The misbehavior occurs only with DTLS_VERIFY_PEERS_ON_RESUMPTION_THRESHOLD values larger than 0.
Published: 2022-07-29T13:20:10.000Z
Updated: 2024-08-03T00:39:08.153Z Reference links |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2021-34433 |
vulnerable | 2026-06-03 14:44:45.031206 |
Details available
In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side's signature on the client side, if that signature is not included in the server's ServerKeyExchange.
Published: 2021-08-20T17:10:10.000Z
Updated: 2024-08-04T00:12:50.235Z Reference links |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2020-27222 |
vulnerable | 2026-06-03 14:42:17.854386 |
Details available
In Eclipse Californium version 2.3.0 to 2.6.0, the certificate based (x509 and RPK) DTLS handshakes accidentally fails, because the DTLS server side sticks to a wrong internal state. That wrong internal state is set by a previous certificate based DTLS handshake failure with TLS parameter mismatch. The DTLS server side must be restarted to recover this. This allow clients to force a DoS.
Published: 2021-02-03T15:45:13.000Z
Updated: 2024-08-04T16:11:36.000Z Reference links |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.