← Back to Feed CACHED · 2026-07-01 01:20:26 · CACHE_KEY CVE-2025-32990
CVE-2025-32990 · CWE-122 · Disclosed 2025-07-10

A heap-buffer-overflow

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A one-byte overrun in a certificate-generation CLI that only fires when an admin feeds it a poisoned template file

GnuTLS ships certtool, a command-line utility administrators use to generate CSRs, self-signed certs, and private keys from human-editable template files. The bug is a classic off-by-one heap overflow (CWE-122) in the template parser: crafted input in a template can overrun a heap buffer by a single byte during processing. Affected versions are GnuTLS prior to 3.8.7 across the 3.7.x and 3.8.x lines; distro-backported fixes landed for RHEL 8/9, Debian bookworm, Ubuntu 22.04/24.04, and SUSE in the weeks following disclosure. The *library* side (libgnutls) — which is what web servers, VPNs, and email daemons actually link — is not affected; the flaw lives in the certtool binary's template code path only.

The vendor score of 6.5 MEDIUM with vector AV:N/AC:L/PR:N/UI:N is misleading. AV:N here is a scoring artifact: it implies remote reachability, but the only way this triggers is if someone runs certtool --generate-request --template <attacker-file> against a file they don't control. That is not a network vulnerability in any operational sense. Confidentiality impact is None, integrity and availability are Low, and there is no path to code execution demonstrated. Real-world severity is LOW — this is a hygiene patch, not a fire.

"Off-by-one in certtool template parsing — an admin CLI tool. No server, no daemon, no network path. Vendor MEDIUM is generous."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker crafts a malicious GnuTLS template file

The attacker produces a template file containing field values shaped to trigger the off-by-one during certtool's parsing pass. Public PoCs on the oss-security list demonstrate a crash reproducer using long dn/cn field values. No weaponized RCE exploit has surfaced.
Conditions required:
  • Knowledge of the vulnerable field parser (public)
  • GnuTLS < 3.8.7 on target
Where this breaks in practice:
  • A single-byte heap overrun rarely reaches useful control-flow hijack without a companion info-leak
  • glibc heap hardening (tcache double-free checks, safe-linking) blunts one-byte overwrites
Detection/coverage: No scanner signatures required — this is a static content file. YARA on template files is pointless.
STEP 02

Delivery: get the file in front of certtool

The template only matters if an administrator or automation pipeline actually invokes certtool against it. Typical delivery vectors: a compromised internal CA workflow, a CI/CD job that generates CSRs from a git-tracked template, or social engineering an ops engineer.
Conditions required:
  • An admin or pipeline that runs certtool on attacker-influenced input
  • Write access to the template location or PR merge on the repo
Where this breaks in practice:
  • certtool is not run by unprivileged users or services on a schedule — it is an interactive admin tool
  • CI pipelines that use it typically consume a *committed* template controlled by change review
  • The library side (libgnutls) linked by nginx/apache/postfix/openvpn is not on this code path
Detection/coverage: EDR process-creation telemetry on certtool invocations is trivial; almost no baseline noise.
STEP 03

Trigger the off-by-one during template parse

certtool processes the template, overruns the heap buffer by one byte, and typically crashes or corrupts an adjacent heap chunk header. On most builds this manifests as a SIGABRT from glibc's malloc consistency checks.
Conditions required:
  • Vulnerable certtool binary reached
Where this breaks in practice:
  • Modern glibc (2.32+) tcache and safe-linking mitigations
  • Distro builds ship with FORTIFY_SOURCE=2, stack canaries, PIE, full RELRO
Detection/coverage: Crash telemetry via ABRT/systemd-coredump; unusual certtool exits.
STEP 04

Impact ceiling: DoS or narrow integrity impact

The realistic outcome is certtool aborting mid-generation (availability impact Low) or emitting a corrupted CSR/cert (integrity impact Low). There is no published path to arbitrary code execution, no privilege escalation, no network foothold. The impact is bounded to the invoking user's session on the host that ran the CLI.
Conditions required:
  • Successful trigger
Where this breaks in practice:
  • The process is short-lived; a crash is annoying, not damaging
  • Output artifacts are typically reviewed before being loaded into a CA or trust store
Detection/coverage: Zero exploitation activity observed in the wild.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed. Not tracked by CISA KEV, no vendor IR reports, no ransomware affiliate use.
Proof-of-conceptCrash reproducer posted to oss-security and referenced in the Red Hat bugzilla; no weaponized RCE exploit public.
EPSS0.0072 (~0.7%) — bottom quartile; FIRST models it as unlikely to be exploited in the next 30 days.
CISA KEVNot listed.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L = 6.5 MEDIUM. AV:N is a scoring artifact — real attack vector is Local via crafted file.
Affected versionsGnuTLS < 3.8.7; all 3.7.x and 3.8.x builds before the fix.
Fixed versionsUpstream 3.8.7; RHEL 8/9 backports in gnutls-3.6.16-8.el8_10 / gnutls-3.7.6-24.el9_5; Debian bookworm 3.7.9-2+deb12u4; Ubuntu 24.04 3.8.3-1.1ubuntu3.3.
Exposure surface (Shodan/Censys)Not measurable — certtool is a CLI, not a listening service. Library-linked daemons are not on the vulnerable code path.
Disclosed2025-07-10 via GnuTLS security list, credited to a Red Hat internal reporter.
Component roleAdmin CLI (certtool). libgnutls — the library used by nginx, apache, exim, openvpn, cups — is unaffected.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The single most decisive factor is that the flaw lives in an admin CLI tool (certtool) invoked interactively against files the operator controls — not in the libgnutls library that daemons link. There is no network path, no privileged service surface, and the impact ceiling is a crash or corrupted CSR, not code execution.

HIGH Downgrade to LOW
HIGH No library-side (libgnutls) exposure
MEDIUM No RCE path materializing later — off-by-one heap overruns occasionally get weaponized, but no researcher has done so here in 12+ months

Why this verdict

  • Attack vector is Local, not Network. The CVSS AV:N is inherited from GnuTLS's general threat model; the actual trigger requires feeding certtool a file. Compounding downward pressure #1.
  • No service surface. certtool is not a daemon, not a listener, not spawned by any listening process. EDR won't see baseline invocations. Compounding downward pressure #2.
  • Impact ceiling is DoS + narrow integrity. CVSS C:N/I:L/A:L — no code execution demonstrated, no privilege change, no lateral movement primitive. Compounding downward pressure #3.
  • Role multiplier — typical role (admin workstation / CA operator laptop): chain succeeds only insofar as certtool crashes; blast radius = one shell session. No fleet impact.
  • Role multiplier — high-value role (internal PKI / ADCS-equivalent operators): even here, the artifact is reviewed before being loaded into a trust store; the chain does not reach domain or fleet compromise. Floor does not lift above LOW.
  • Role multiplier — CI/CD pipelines using certtool: template files are change-controlled in git; delivering a malicious template requires PR merge access, at which point the attacker already has more direct paths.
  • libgnutls is not affected — the internet-facing daemons that matter (TLS termination, VPN, mail) are not exposed via this code path. Installed-base share of certtool being run against untrusted input is well under 1%.

Why not higher?

MEDIUM would require a plausible path to code execution or a service-side exposure. Neither exists: it's an off-by-one in an interactive CLI with hardened distro toolchains, and no researcher has demonstrated control-flow hijack in 12+ months since disclosure. HIGH would require a role multiplier landing in a domain-scale blast radius, which the certtool workflow does not provide.

Why not lower?

IGNORE is off the table because the flaw is real, upstream shipped a fix, and there is a non-zero (if contrived) integrity path via corrupted CSRs entering a CA workflow. It stays in the patch backlog under normal hygiene cadence rather than being fully waived.

05 · Compensating Control

What to do — in priority order.

  1. Roll GnuTLS to 3.8.7 (or distro backport) during the next regular patch window — No mitigation SLA applies at LOW — fold this into standard OS-package hygiene and land within the noisgate remediation window of 365 days. On RHEL/Ubuntu, dnf update gnutls-utils / apt install gnutls-bin is sufficient — no service restart required because the flaw is in the utility binary, not the library.
  2. Restrict who can drop files into certtool template directories — If you have automation that invokes certtool from a shared path, tighten filesystem ACLs so only trusted operators/service accounts can write templates. Kills the delivery step regardless of patch state.
  3. Move CSR generation to reviewed pipelines — Templates consumed by CI/CD should live in a git repo with mandatory PR review and signed commits. This makes a malicious template functionally equivalent to a malicious code commit — same review gate applies.
  4. Alert on interactive certtool invocations outside expected admin sessions — EDR process-creation rule: certtool --generate-* from a non-admin user or from a service account with no historical baseline. Low noise, high signal because certtool has very few legitimate callers.
What doesn't work
  • Blocking inbound network traffic — irrelevant; the CVSS AV:N scoring does not reflect an actual network path.
  • Restarting nginx/apache/postfix after upgrading libgnutls — the library isn't the vulnerable code and the restart is a waste of change-window budget for this CVE.
  • WAF rules or TLS inspection — nothing traverses the wire in this bug.
  • Rotating certificates — the flaw is in certificate *generation tooling*, not in the trust chain; rotation neither exposes nor mitigates.
06 · Verification

Crowdsourced verification payload.

Run this on each Linux host that ships GnuTLS utilities (the gnutls-utils / gnutls-bin package). Invoke as ./check-cve-2025-32990.sh — no root required, it only reads package metadata. Outputs VULNERABLE, PATCHED, or UNKNOWN with an exit code (0/1/2).

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# noisgate check for CVE-2025-32990 (GnuTLS certtool off-by-one)
# Compares the installed gnutls-utils / gnutls-bin version against upstream 3.8.7
# and against known distro backports.
set -u

MIN_UPSTREAM="3.8.7"

ver_ge() {
  # returns 0 if $1 >= $2 (semver-ish)
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

if ! command -v certtool >/dev/null 2>&1; then
  echo "UNKNOWN: certtool not installed on this host"
  exit 2
fi

RAW="$(certtool --version 2>/dev/null | head -n1)"
VER="$(echo "$RAW" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"

if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse certtool version from: $RAW"
  exit 2
fi

# Check distro-backport package versions where the upstream number is <3.8.7
# but the security fix is present.
PKG_VER=""
if command -v rpm >/dev/null 2>&1; then
  PKG_VER="$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' gnutls-utils 2>/dev/null | head -n1)"
elif command -v dpkg-query >/dev/null 2>&1; then
  PKG_VER="$(dpkg-query -W -f='${Version}\n' gnutls-bin 2>/dev/null | head -n1)"
fi

echo "certtool binary version: $VER"
echo "distro package version : ${PKG_VER:-n/a}"

# Known-good distro package versions (add as your fleet requires)
case "$PKG_VER" in
  3.6.16-8.el8_10*|3.7.6-24.el9_5*|3.7.9-2+deb12u4*|3.8.3-1.1ubuntu3.3*)
    echo "PATCHED: distro backport detected"
    exit 0
    ;;
esac

if ver_ge "$VER" "$MIN_UPSTREAM"; then
  echo "PATCHED: upstream >= $MIN_UPSTREAM"
  exit 0
fi

echo "VULNERABLE: certtool $VER < $MIN_UPSTREAM and no known backport matched"
exit 1
07 · Bottom Line

If you remember one thing.

TL;DR
Treat this as backlog hygiene, not an incident. Monday morning: confirm your patch management is already scheduled to pull gnutls-utils / gnutls-bin from your distro's stable channel in the next quarterly window — that's the noisgate remediation SLA of ≤365 days for a LOW verdict, and there is no noisgate mitigation SLA because the impact ceiling is a crash or malformed CSR in an admin CLI. Do not burn a change window restarting TLS-terminating services (nginx/apache/postfix/openvpn) — libgnutls is not on the vulnerable code path. The only exception is if your internal PKI operators use certtool against templates sourced from ticket attachments or shared drives; in that case, tighten the template source-of-truth to a reviewed git repo and skip forward to patching within the next 30 days as a precaution.

Sources

  1. NVD — CVE-2025-32990
  2. Red Hat Security Advisory / Bugzilla
  3. GnuTLS upstream release notes 3.8.7
  4. Debian security tracker
  5. Ubuntu CVE database
  6. SUSE CVE database
  7. FIRST EPSS lookup
  8. MITRE CWE-122: Heap Buffer Overflow
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.