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 s…

published 2021-08-20 5y ago modified 2026-06-17 4mo ago also EUVD-2021-21089

cvss: 7.5; version 3.1, NVD
cisa kev: Not listed; not in CISA's catalog
epss: 0.3%; EPSS 0.3% chance of exploitation in 30 days, percentile 27%
public exploits: 0; none known

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.

Patch / fix

fixed in 1

eclipse californium 2.6.5

Is CVE-2021-34433 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Exploit prediction

0.34% chance of exploitation in the next 30 days, higher than 27% of all scored CVEs (FIRST EPSS, 2026-11-09).

CVSS scores

assigned by	version	score	vector
NVD	3.1	7.5	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
NVD	2.0	5.0	AV:N/AC:L/Au:N/C:N/I:P/A:N

Affected products

The Eclipse Foundation Eclipse Californium

Classification

Weakness

CWE-322 Key Exchange without Entity Authentication
CWE-347 Improper Verification of Cryptographic Signature

References

bugs.eclipse.org /bugs/show_bug.cgi?id=575281
issue-tracking, vendor-advisory

Sources

CVE List CVE-2021-34433
NVD CVE-2021-34433

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.