A remotely exploitable vulnerability in the FRRouting (FRR) networking suite can crash OSPF routers with a single malicious packet—but only if a specific debug setting is turned on. The flaw, assigned CVE-2025-61105, affects all FRR releases from version 4.0 through 10.4.1 and carries a CVSS v3.1 score of 7.5 (High), signaling a severe availability risk. The fix is a small, upstreamed code change, yet the window of exposure remains wide for any network where detailed OSPF packet debugging has been enabled and forgotten.

The Vulnerability Breakdown

The bug lives in the OSPF opaque LSA handling code inside the ospfd daemon. When an operator turns on debug ospf packet all send/recv detail, the daemon routes packet content through a chain of show helpers—functions that render internal data structures into human-readable output on the VTY (virtual terminal). One of those helpers, part of the show_vty_link_info family in ospf_ext.c, lacks a proper NULL check for the VTY context or certain opaque LSA substructures. An attacker who crafts a malicious OSPF Link State Update containing carefully malformed opaque LSA elements can trigger a NULL pointer dereference, crashing ospfd instantly.

The attack works over the network, requires no authentication, and leaves behind a crashed routing process. Because the vulnerable path is exercised only when verbose debug mode is active, the exploitability is conditional—but that condition is more common than many administrators realize. Troubleshooting sessions often leave debug flags enabled, and in cloud or virtualized environments, temporary diagnostic modes can persist indefinitely.

Upstream developer s1awwhy submitted a pull request (#19480) that closes the hole by adding defensive NULL checks and falling back to safe logging (zlog) when the VTY pointer is absent. The commit, fdd957408605d4a1766225630aafc7e6b7c3daf3, was merged into the FRR master branch and subsequently landed in post‑10.4.1 releases. The National Vulnerability Database assigned the CVE on 27 October 2025, with a clear availability impact: “A remote unauthenticated attacker may cause a denial-of-service condition.”

Who Is Affected

This vulnerability touches a surprisingly broad audience, though the immediate risk depends on how FRR is deployed.

Home users and hobbyists who run FRR on a Raspberry Pi, in a WSL instance, or inside a lab container for learning OSPF are not typical targets—but they are not immune. If you’ve ever typed debug ospf packet all send/recv detail to watch routing updates and forgot to turn it off, your device is a soft target on any network that can send it OSPF packets. Even a brief exposure on a home LAN can lead to a crash.

IT professionals and network engineers managing corporate WANs, data center fabrics, or ISP edges face the sharpest consequences. A crashed ospfd means lost adjacencies, withdrawn routes, and—depending on topology—full traffic blackholes. Re‑convergence can trigger secondary failures, CPU spikes, and application‑layer timeouts. The vulnerability is especially dangerous for single‑node routers or non‑redundant sites where no failover path exists. Several security trackers note that the mere act of enabling detailed OSPF debug on a production router is a ticking time bomb, and the fix cannot be applied too quickly.

Developers and integrators who embed FRR in custom appliances or virtual network functions must incorporate the patch into their build pipelines. Distribution vendors lag behind: Debian and Ubuntu trackers, for example, initially marked the package fix as “deferred” on several release branches. If you rely on vendor‑supplied packages, you cannot assume the update is automatically available.

A Timeline of Events

The discovery followed a familiar yet effective pattern. In August 2025, a researcher opened GitHub issue #19471 to report “NULL pointer dereference in ospf opaque LSA show functions.” The FRR community acknowledged the report, and by mid‑October the patch was under review. Pull request #19480 landed on 25 October, the CVE was reserved on 27 October, and public advisories began circulating immediately afterward. NVD’s final analysis locked in the 7.5 score, citing the low attack complexity and the condition that merely enables debugs. The FRR team rolled the fix into the 10.4.2 maintenance release and later tags, but packaging for downstream operating systems proceeded at varying speeds.

This family of vulnerabilities—debug dump helpers missing NULL checks—is not new. In the same timeframe, similar issues were reported for other OSPF and IS‑IS debugging paths. The collective lesson is clear: any code that formats externally controlled protocol data for human consumption is a potential attack surface that deserves the same rigor as production packet parsing.

Immediate Steps to Protect Your Network

Act on multiple fronts simultaneously. The recommendations below are ordered by urgency.

1. Disable OSPF Detailed Debugging Now

Run the following command on every FRR instance you manage:

no debug ospf packet all send/recv detail

Confirm the change via vtysh and check daemon logs to ensure no debug flags remain. If you use configuration automation (Ansible, Salt, custom scripts), push this change immediately as a one‑line commit.

2. Filter OSPF Traffic at Network Boundaries

OSPF runs over IP protocol 89. On routers and layer‑3 switches bordering untrusted networks, apply access control lists that deny OSPF from any peer that is not a trusted adjacency partner. Example (Cisco‑style):

access-list 100 deny 89 any any
access-list 100 permit ip any any

At the host level, use iptables or nftables on Linux systems to drop OSPF from unexpected sources. For Windows‑based appliances (including WSL), apply similar rules with Windows Defender Firewall or third‑party tools.

3. Apply the Upstream Patch or Upgrade

If you build FRR from source, cherry‑pick commit fdd957408605d4a1766225630aafc7e6b7c3daf3 from PR #19480 into your release branch. For those using upstream tarballs, pull FRR 10.4.2 or any subsequent tag that includes the fix. Verify the patch with:

git log --oneline | grep fdd957408605

If you depend on distribution packages (Debian, Ubuntu, RHEL, etc.), consult your vendor’s security advisory. Do not assume a generic system update carries the fix; check the package changelog for the CVE reference. For example, Debian’s tracker shows the status of frr under buster, bullseye, and bookworm.

4. Verify Remediation

In a lab, replicate the vulnerable condition and send a crafted LS Update (use the public proof‑of‑concept if available, or a trusted test vector). Confirm that ospfd no longer crashes and that the daemon logs a graceful message through zlog. For production systems where active testing is dangerous, rely on code‑presence verification and vendor version mappings.

5. Harden Monitoring and Response

Add alerts for repeated ospfd crashes, adjacency flaps, or unusual OSPF traffic from unrecognized sources. If you run a SIEM or log aggregation platform, create correlation rules that flag sudden routing process restarts.

The Road Ahead

CVE-2025-61105 is a textbook example of how diagnostic tools, designed to aid human operators, become accidental weapons when left unguarded. The fix is trivial—a few lines of defensive C—but the operational gap is cultural: organizations must treat debug facilities with the same caution as production configuration. Expect more security advisories targeting similar code paths across routing and switching platforms.

For the FRR project, the responsible disclosure and swift merge demonstrate a maturing security process. For network teams, the wake‑up call is to retire the habit of enabling verbose packet dumps without airtight off‑boarding procedures. If your routers speak OSPF, the command to run right now is no debug ospf packet all send/recv detail.