Eclipse Californium
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in Eclipse Californium.
By the Year
In 2025 there have been 0 vulnerabilities in Eclipse Californium. Californium did not have any published security vulnerabilities last year.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2025 | 0 | 0.00 |
| 2024 | 0 | 0.00 |
| 2023 | 0 | 0.00 |
| 2022 | 2 | 7.85 |
| 2021 | 1 | 7.50 |
| 2020 | 0 | 0.00 |
| 2019 | 0 | 0.00 |
| 2018 | 0 | 0.00 |
It may take a day or so for new Californium vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Eclipse Californium Security Vulnerabilities
Eclipse Californium is a Java implementation of RFC7252 - Constrained Application Protocol for IoT Cloud services
CVE-2022-39368
8.2 - High
- November 10, 2022
Eclipse Californium is a Java implementation of RFC7252 - Constrained Application Protocol for IoT Cloud services. In versions prior to 3.7.0, and 2.7.4, Californium is vulnerable to a Denial of Service. Failing handshakes don't cleanup counters for throttling, causing the threshold to be reached without being released again. This results in permanently dropping records. The issue was reported for certificate based handshakes, but may also affect PSK based handshakes. It generally affects client and server as well. This issue is patched in version 3.7.0 and 2.7.4. There are no known workarounds. main: commit 726bac57659410da463dcf404b3e79a7312ac0b9 2.7.x: commit 5648a0c27c2c2667c98419254557a14bac2b1f3f
Improper Resource Shutdown or Release
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
CVE-2022-2576
7.5 - High
- July 29, 2022
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.
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
CVE-2021-34433
7.5 - High
- August 20, 2021
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.
Improper Verification of Cryptographic Signature
Stay on top of Security Vulnerabilities
Want an email whenever new vulnerabilities are published for Eclipse Californium or by Eclipse? Click the Watch button to subscribe.
