CVE-2025-7208: Medium Heap Overflow in plan9port libsec x509

CVE-2025-7208 is a medium severity (CVSS 5.5) heap buffer overflow in the edump function of plan9port's libsec library. plan9port is a rolling release with no version numbers, so the record points to patch commit b3e06559475b0130a7a2fb56ac4d131d13d2012f as the fix. Update by rebuilding from a newer upstream commit, and avoid parsing untrusted certificates until you have.

What's affected

The record names 9fans plan9port "up to 9da5b44", and the function edump in src/libsec/port/x509.c. Because the project uses rolling releases, the record says version details for affected and updated releases are not available. Anything built from a commit at or before 9da5b44 is in scope.

The record gives the patch identifier b3e06559475b0130a7a2fb56ac4d131d13d2012f and recommends applying it. That commit is listed on the plan9front git server, which suggests the fix came from the related plan9front code. I tried to open the commit page and could not read it, so I cannot describe the change itself. Read it yourself before you merge it.

The public bug report on the plan9port tracker (issue 710) describes a heap buffer overflow found with a fuzzing harness and an address sanitizer, against commit 9da5b44. The record says exploit details are public. It does not say the flaw is exploited in the wild, and the KEV flag is false.

The severity needs a note. The description text, which follows the VulDB wording, calls the issue "critical". The CVSS 3.1 score in the record is 5.5 with an adjacent network vector (AV:A) and low privileges (PR:L), which is medium. This post uses the score.

The weaknesses are CWE-119 (memory buffer bounds) and CWE-122 (heap based overflow).

How to check if you're exposed

If you installed plan9port from a package manager, you do not have a version number to compare. Look at the commit your build came from. For a source checkout:

cd /usr/local/plan9
git log -1 --format=%H
git merge-base --is-ancestor b3e06559475b0130a7a2fb56ac4d131d13d2012f HEAD && echo "patch ancestry present"

The second command only works if your checkout contains the commit by that hash. The patch was published in the plan9front repository, so the hash may not exist in a plain plan9port history. In that case, open src/libsec/port/x509.c and compare the edump function with the patched version in the upstream commit.

Then ask whether your systems pass untrusted certificate data to tools built on libsec. If you only use plan9port as a desktop toolkit and never parse outside certificates with it, your real exposure is small.

What to do now

1. List the machines that have plan9port installed and how they got it.
2. Find the commit each build came from. If it is 9da5b44 or earlier, treat it as affected.
3. Rebuild from a newer upstream checkout, or apply the patch from the record after reading it.
4. Until then, do not feed untrusted certificate files to tools that use libsec.
5. Check the plan9port issue tracker for the maintainers' own notes before you close this out.

Why it matters

A heap overflow writes past the end of a memory block. The result ranges from a crash to memory corruption that an attacker can shape, depending on the code around it. The record scores the impact as low across confidentiality, integrity and availability, and the adjacent network vector limits who can reach it, which explains the medium score.

Certificate parsers are a classic home for this kind of bug. They read length fields from files that someone else controls, and one missed check is enough. Fuzzing found this one, which is a good sign for the project. The practical lesson for teams is that rolling release software needs a commit level inventory, not a version number.

Quick check

Sources

• CVE-2025-7208 on Safeguard Gold
• plan9port issue 710 on GitHub
• Patch commit on git.9front.org (could not be read when I checked)

Last reviewed: 18 October 2026.