CVE-2020-26243 json
Memory leak in nanopb
published 5y ago modified 4mo ago also GHSA-85rr-4rh9-hhwh , PYSEC-2026-684 , EUVD-2020-1450
- cvss
- 7.5
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 2.7%
- EPSS 2.7% chance of exploitation in 30 days, percentile 85%
- public exploits
- 0
- none known
Summary
Nanopb is a small code-size Protocol Buffers implementation. In Nanopb before versions 0.4.4 and 0.3.9.7, decoding specifically formed message can leak memory if dynamic allocation is enabled and an oneof field contains a static submessage that contains a dynamic field, and the message being decoded contains the submessage multiple times. This is rare in normal messages, but it is a concern when untrusted data is parsed. This is fixed in versions 0.3.9.7 and 0.4.4. The following workarounds are available: 1) Set the option `no_unions` for the oneof field. This will generate fields as separate instead of C union, and avoids triggering the problematic code. 2) Set the type of the submessage field inside oneof to `FT_POINTER`. This way the whole submessage will be dynamically allocated and the problematic code is not executed. 3) Use an arena allocator for nanopb, to make sure all memory can be released afterwards.
Patch / fix
- pypi nanopb 0.3.9.7, 0.4.4
- nanopb_project nanopb 0.3.9.7, 0.4.4
- nanopb Debian 14, Debian 13, Debian 12 0.4.4-1
debian advisories DEBIAN-CVE-2020-26243
- nanopb Ubuntu Pro 20.04 LTS 0.4.1-1ubuntu0.1~esm1
ubuntu advisories UBUNTU-CVE-2020-26243
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- nanopb openSUSE Tumbleweed 0.4.5-1.3
opensuse advisories openSUSE-SU-2024:11074-1
- github.com/nanopb/nanopb@4fe2359 commit
- github.com/nanopb/nanopb/issues/615 advisory
Is CVE-2020-26243 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2020-26243 updated cvss 7.5
nanopb: oneof fields with PB_ENABLE_MALLOC can leak memory
-
Red Hat OpenShift Service Mesh 1 servicemesh-proxyaffected: no fix planned “Will not fix”
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
2.66% chance of exploitation in the next 30 days, higher than 85% of all scored CVEs (FIRST EPSS, 2026-11-09).
Exploits and checks
- github.com https://github.com/nanopb/nanopb/issues/615 referenced PoC, tagged "exploit" by a source, unverified
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| NVD | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| NVD | 2.0 | 4.3 | AV:N/AC:M/Au:N/C:N/I:N/A:P |
| OSV | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| GitHub | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| pypi | nanopb | >=0.3.2, <0.3.9.7 >=0.4.0, <0.4.4 |
0.3.9.7 0.4.4 |
Affected products
- nanopb nanopb
Classification
References
-
github.com
/nanopb/nanopb/commit/4fe23595732b6f1254cfc11a9b8d6da900b55b0c
web, patch, third-party-advisory
-
github.com
/nanopb/nanopb/issues/615
web, exploit, patch, third-party-advisory
-
github.com
/nanopb/nanopb/security/advisories/GHSA-85rr-4rh9-hhwh
web, third-party-advisory
-
github.com
/nanopb/nanopb/blob/2b48a361786dfb1f63d229840217a93aae064667/CHANGELOG.txt
web, release-notes, third-party-advisory
-
nvd.nist.gov
/vuln/detail/CVE-2020-26243
advisory
-
pypi.org
/project/nanopb
package
-
github.com
/advisories/GHSA-85rr-4rh9-hhwh
advisory
Sources
- CVE List CVE-2020-26243
- GitHub Advisory GHSA-85rr-4rh9-hhwh
- NVD CVE-2020-26243
- OSV PYSEC-2026-684
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.