CVE-2025-65411: 
NixOS vulnerability analysis and mitigation

CVE-2025-65411 is a NULL pointer dereference vulnerability (CWE-476) in the src/path.c component of GNU Unrtf v0.21.10 that allows attackers to cause a Denial of Service (DoS) by injecting a crafted payload into the search_path parameter. The vulnerability was reported on November 4, 2025, via Savannah bug #67671, with the upstream maintainer acknowledging and fixing it on November 5, 2025. It was publicly disclosed via CVE assignment on December 30, 2025. Only GNU Unrtf version 0.21.10 is confirmed affected. The CVSS v3.1 base score is 7.5 (High), assigned by CISA-ADP (GitHub PoC, GNU Mailing List).

The root cause is an off-by-one boundary check error in src/main.c during command-line option parsing for the -P flag (configuration search path). When -P is the last argument, the check if (i + 1 > argc) incorrectly evaluates to false, causing the parser to unconditionally execute argv[++i], which reads argv[argc] — a NULL pointer by C convention. The NULL value is then assigned to search_path, which is subsequently dereferenced in check_dirs() within src/path.c without a NULL guard, triggering a segmentation fault (SIGSEGV). The upstream fix, available at Mercurial revision 755925d817fe, corrects the boundary check to i + 1 >= argc and adds validation of argv[i+1] for NULL and empty strings before assignment (GitHub PoC, GNU Mailing List).

Successful exploitation causes the GNU Unrtf process to crash with a segmentation fault (SIGSEGV), resulting in a Denial of Service for any workflow or automated pipeline that depends on Unrtf for RTF document processing. There is no confidentiality or integrity impact — the vulnerability does not expose sensitive data or allow data corruption. In environments where Unrtf is invoked by scripts or automated tooling that processes externally supplied arguments, an attacker who can influence the command-line invocation may be able to repeatedly crash the service, disrupting document conversion workflows (GitHub PoC).

A public proof-of-concept is available on GitHub, demonstrating that the vulnerability is trivially triggered by invoking unrtf -P without a required path argument. The EPSS score is 0.018% (0.000180), indicating a very low probability of exploitation in the wild. There is no evidence of active in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. While the CVSS vector includes a network attack vector, the actual exploitation is a local command-line invocation, making real-world network-based exploitation contingent on Unrtf being wrapped in a network-accessible service (GitHub PoC).

1. Identify target: Locate systems running GNU Unrtf v0.21.10, particularly those where Unrtf is invoked by scripts, web services, or automated document-processing pipelines that accept external input.
2. Craft malicious invocation: Prepare a command-line invocation of unrtf that includes the -P flag as the final argument with no subsequent path parameter: ./unrtf -P.
3. Trigger the crash: Execute the crafted invocation. The off-by-one boundary check in main() fails to detect the missing argument, causing argv[argc] (NULL) to be assigned to search_path.
4. NULL pointer dereference: When check_dirs() in src/path.c subsequently dereferences search_path, a segmentation fault (SIGSEGV) is raised, crashing the process.
5. Achieve DoS: In automated pipelines where Unrtf is called repeatedly, the attacker can supply crafted inputs that trigger this condition on each invocation, causing persistent service disruption (GitHub PoC).

• Process: Unexpected termination of the unrtf process with exit code indicating a segmentation fault (SIGSEGV / signal 11); core dump files (core or core.<pid>) generated in the working directory of the Unrtf process.
• Logs: System logs (e.g., /var/log/syslog, /var/log/messages) recording segfault entries such as unrtf[<pid>]: segfault at 0 ip ... error 4; application logs showing repeated Unrtf process failures or unexpected exits.
• File System: Presence of core dump files in directories where Unrtf is executed, particularly if core dumps are enabled on the system.
• Command History / Audit Logs: Audit trail entries showing invocations of unrtf -P without a following path argument, especially from automated scripts or web-facing services (GitHub PoC).

The upstream fix is available in the GNU Unrtf Mercurial repository at revision 755925d817fe, which corrects the off-by-one boundary check for the -P option and prevents search_path from being assigned a NULL value. Users should upgrade to any Unrtf release that includes this changeset; consult the Unrtf release notes or Mercurial history to identify the first patched release. As an interim workaround, restrict access to systems running Unrtf v0.21.10, implement input validation in any wrapper scripts to ensure -P is always followed by a valid path argument, and consider disabling or isolating Unrtf services if they are not essential (GitHub PoC, GNU Mailing List).

The vulnerability was acknowledged by GNU Unrtf maintainer Jean-Francois Dockes within one day of the private report, with a fix committed to the upstream Mercurial repository on November 5, 2025. The disclosure was noted by automated vulnerability tracking services including ENISA EUVD, VulDB, and INCIBE-CERT. No significant broader media coverage or notable researcher commentary beyond the original disclosure by researcher "wheat MAX" has been identified (GNU Mailing List).