CVE-2026-37457 is a high-severity denial-of-service flaw disclosed in May 2026 in FRRouting’s BGP FlowSpec handling, where a crafted FlowSpec component can trigger an off-by-one out-of-bounds write in
This is the sort of CVE that looks narrow until you map where FRRouting actually lives. FRR is not a consumer desktop package; it is a routing suite used in Linux routers, network appliances, labs, data centers, Kubernetes-adjacent fabrics, and cloud-native networking projects. A crash in
The fix for CVE-2026-37457 is almost comically small: the relevant commit changes loop bounds so a counter stops at the end of an array instead of stepping one slot beyond it. In human terms, the vulnerable code allowed too many chained FlowSpec operators to be decoded into an internal match-value array. Once the parser accepted one operator too many, the program could write outside the intended memory region.
That is the classic off-by-one failure, the kind every C programmer learns to fear because it often hides in code that otherwise looks reasonable. If an array has five valid positions, a comparison that permits position five instead of stopping at position four is enough to turn a parser into a crash trigger. In routing code, the parser is often reachable through protocol input, which makes the distinction between a local bug and a network-facing operational problem very thin.
The published CVSS 3.1 vector tells the same story in compressed form: network attack vector, low attack complexity, no privileges required, no user interaction, unchanged scope, and high availability impact. There is no confidentiality or integrity claim here. The risk is not that an attacker reads routing secrets or rewrites policy through this bug; the risk is that they can knock over the component responsible for understanding BGP FlowSpec data.
That distinction matters. Security teams have spent years triaging remote code execution above all else, often leaving denial-of-service bugs in the “patch when convenient” pile. But a denial of service in a routing daemon occupies a different category from a nuisance crash in a peripheral service. Availability is the product.
That elegance is also why parser bugs in FlowSpec deserve attention. FlowSpec messages are rich, structured, and policy-heavy; they are not simple route announcements containing only a prefix and a next hop. They encode components, operators, and match semantics that the receiving implementation must parse precisely. Every extra bit of expressiveness becomes a little more attack surface.
The vulnerability description points to a crafted FlowSpec component, not generic BGP traffic. That narrows the exposure to deployments where an attacker can get such data processed by FRR’s BGP daemon. In many production environments, BGP sessions are authenticated, filtered, and limited to known peers. In too many smaller or hastily built networks, however, routing control planes are trusted more by habit than by design.
FlowSpec also tends to live in environments where the stakes are already high. It is used by service providers, hosting firms, DDoS mitigation platforms, enterprise WANs, and labs that mirror larger production architectures. Those are exactly the places where a service crash can ripple outward: routes withdraw, policies disappear, traffic shifts, monitoring alarms fire, and engineers begin asking whether the network is under attack or simply misconfigured.
But “not catastrophic” is not the same as “unimportant.” A vulnerability can be operationally serious without being glamorous. The attacker’s goal in many real-world incidents is not to steal data from the router; it is to create uncertainty, interrupt connectivity, or force failover at the worst possible time.
The most dangerous misreading would be to say that because this is “only DoS,” it can wait. In routing infrastructure, DoS is often the whole point. If a crafted message can repeatedly crash
There is also a subtler concern: parser bugs in control-plane software tend to test the assumptions of surrounding defenses. Operators often think in terms of BGP neighbor trust, TCP MD5 or TCP-AO protections, TTL security, prefix filters, and peer ACLs. Those controls are valuable, but they do not erase the need to patch implementation flaws. They reduce who can reach the parser; they do not make the parser safe.
That is now normal. Azure, Windows Server estates, developer platforms, security products, virtual appliances, Linux workloads, and hybrid infrastructure all intersect. A Windows admin can be responsible for an environment where the critical routing component is not a Windows service at all. The old boundary between “Microsoft patching” and “Linux network package patching” has been dissolved by hybrid IT.
This is especially true in organizations that run Windows-heavy endpoints but Linux-heavy infrastructure. Active Directory, Entra ID, Windows Server, Hyper-V, SQL Server, and Intune may define the administrative center of gravity, while FRR or FRR-derived components quietly move traffic in a lab, container platform, virtual network appliance, or branch router. When that routing layer stumbles, Windows users experience it as an outage, not as a Linux issue.
The practical implication is that asset inventory needs to include routing software by name and version, not merely device model and operating system family. It is not enough to know that a box is “a router” or “a Linux appliance.” If FRR is present, teams need to know which branch, which package source, which vendor build, and whether FlowSpec is enabled or accepted from peers.
For administrators, that gap is where risk lives. The upstream project may have committed a patch. A distribution may have imported it into unstable. A vendor may still be testing a backport. An appliance image may lag behind both. A container image may never update unless the team rebuilds it. A lab VM may keep running the old package forever because nobody considers it production, right up until production depends on it.
FRR’s own versioning adds another layer. The CVE description calls out stable/10.0, while NVD’s configuration analysis identifies FRRouting 10.0. Debian’s package status reflects distro versions that do not map cleanly to upstream names in the way hurried scanners sometimes imply. That means vulnerability management teams should resist the urge to rely on a single string match.
The best approach is boring and effective: compare installed package versions against vendor advisories, inspect whether the relevant patch is present, and verify the behavior of your actual build. For source-built FRR, that means checking the commit history or applying the patch directly. For packaged FRR, that means waiting for and deploying the distribution’s security update rather than assuming an upstream tag tells the whole story.
This is why CVE-2026-37457 belongs in a WindowsForum discussion. The Windows estate is often the visible part of a larger dependency chain. Users notice when file shares pause, remote desktop sessions drop, VPN routes disappear, domain controllers become unreachable, or line-of-business applications time out. They do not care whether the root cause was a malformed FlowSpec component processed by a Linux routing daemon.
Hybrid environments make the issue more likely, not less. Many organizations now run Windows clients, Linux servers, cloud-managed firewalls, SD-WAN appliances, Kubernetes clusters, and virtual routers in a single operational fabric. FRR appears in open networking stacks precisely because it is capable and flexible. That same flexibility means it may be tucked into places the Windows team does not routinely patch.
There is a cultural problem here too. Windows patching has become process-heavy, calendar-driven, and audit-friendly. Network appliance patching is often more bespoke, more cautious, and more dependent on maintenance windows. Linux routing packages that sit between those worlds can fall through the cracks: not quite part of Patch Tuesday, not quite part of the network vendor’s firmware cycle, and not quite owned by the application team.
For CVE-2026-37457, the first question is whether FRR is present and whether
The second question is whether FlowSpec is configured and from whom it is accepted. If FlowSpec is not in use, the reachable attack surface may be reduced, although administrators should be careful about assuming disabled features are never parsed in unexpected paths. If FlowSpec is accepted only from tightly controlled peers over protected sessions, the risk is different from a route server, lab, or poorly filtered edge that accepts more input than intended.
The third question is what happens when
This is where routing security becomes operational engineering. The patch is necessary, but so is a sober look at control-plane protection, peer filtering, monitoring, and failover behavior. A malformed FlowSpec component should not be able to become a business outage merely because one daemon accepted one bad object.
C remains dominant in routing stacks for good reasons: performance, portability, history, and deep integration with operating system networking internals. But those reasons do not make bounds errors disappear. They simply make defensive coding, fuzzing, code review, and rapid patch distribution non-negotiable.
Off-by-one errors are particularly revealing because they are rarely architectural failures. They are small mistakes with large consequences. A comparison operator, a maximum constant, and an array size fall out of alignment, and suddenly a control-plane parser can write past its intended storage. The fix may be one character, but the discipline required to find every similar edge case is much larger.
The industry’s move toward memory-safe languages will help in some domains, but routing stacks will not be rewritten overnight. In the meantime, the practical answer is layered: sanitize protocol input, fuzz decoders, restrict peers, monitor daemon stability, isolate control-plane services, and update aggressively when parser bugs land. None of that is novel. The problem is consistency.
This is the familiar weakness of CVE-driven operations. The CVE is a starting point, not the final risk assessment. In a Windows-heavy enterprise, the scanner output may land on a security dashboard owned by one team, while the actual FRR instance is managed by a network team, a platform team, or an outsourced provider. The first challenge is not patching. It is ownership.
Administrators should expect some false certainty from tools. A package may appear vulnerable because the version string is old, even though the distro backported the patch. Conversely, a system may appear clean because the scanner lacks visibility into a container image, custom build, or appliance shell. Both errors are common enough that serious environments need verification beyond the dashboard.
That verification does not have to be heroic. Inventory the FRR instances. Check active daemons. Confirm package provenance. Review whether FlowSpec is enabled. Identify accepted BGP peers. Confirm whether the patch that changes the FlowSpec operator bounds check is present. Then test failover behavior under controlled conditions instead of discovering it during an incident.
That is why this bug should be triaged by network role, not by package name alone. A route reflector, edge router, DDoS mitigation node, or FlowSpec controller deserves faster attention than a dormant package on a test VM. Conversely, a noisy scanner finding on an inactive host should not distract from a quieter but more exposed routing daemon in the path of production traffic.
Microsoft’s presence in the disclosure chain is a useful reminder of where enterprise infrastructure has gone. Windows administrators now live in ecosystems where Microsoft advisories, Linux packages, GitHub commits, Debian trackers, cloud images, and network control planes all describe different slices of the same operational reality. A security program that only patches what appears in Windows Update is no longer patching the estate.
CVE-2026-37457 will probably not be remembered as one of the defining vulnerabilities of 2026. It is too narrow, too fixable, and too short on spectacle. But it is a clean example of a more durable truth: modern availability failures often begin as tiny parser mistakes in components nobody sees until they stop working. The organizations that handle this well will not be the ones with the loudest dashboards; they will be the ones that know where their routing software runs, who owns it, and how quickly a one-character fix can move from upstream code into the path their users depend on.
bgp_flowspec_op_decode() within bgpd/bgp_flowspec_util.c. The bug is not a Windows vulnerability, yet it matters to WindowsForum readers because Windows networks increasingly sit behind Linux-based routing stacks, virtual appliances, edge boxes, and cloud images that borrow heavily from open-source routing code. Its lesson is blunt: the route control plane is software, and software memory bugs can become infrastructure outages.This is the sort of CVE that looks narrow until you map where FRRouting actually lives. FRR is not a consumer desktop package; it is a routing suite used in Linux routers, network appliances, labs, data centers, Kubernetes-adjacent fabrics, and cloud-native networking projects. A crash in
bgpd is not “just another daemon restart” when that daemon is participating in the decisions that tell packets where to go.
A One-Character Boundary Check Becomes a Routing Problem
The fix for CVE-2026-37457 is almost comically small: the relevant commit changes loop bounds so a counter stops at the end of an array instead of stepping one slot beyond it. In human terms, the vulnerable code allowed too many chained FlowSpec operators to be decoded into an internal match-value array. Once the parser accepted one operator too many, the program could write outside the intended memory region.That is the classic off-by-one failure, the kind every C programmer learns to fear because it often hides in code that otherwise looks reasonable. If an array has five valid positions, a comparison that permits position five instead of stopping at position four is enough to turn a parser into a crash trigger. In routing code, the parser is often reachable through protocol input, which makes the distinction between a local bug and a network-facing operational problem very thin.
The published CVSS 3.1 vector tells the same story in compressed form: network attack vector, low attack complexity, no privileges required, no user interaction, unchanged scope, and high availability impact. There is no confidentiality or integrity claim here. The risk is not that an attacker reads routing secrets or rewrites policy through this bug; the risk is that they can knock over the component responsible for understanding BGP FlowSpec data.
That distinction matters. Security teams have spent years triaging remote code execution above all else, often leaving denial-of-service bugs in the “patch when convenient” pile. But a denial of service in a routing daemon occupies a different category from a nuisance crash in a peripheral service. Availability is the product.
FlowSpec Is a Scalpel That Cuts Both Ways
BGP FlowSpec exists because networks need a way to distribute traffic-filtering rules quickly. Instead of pushing manual ACL changes across routers during an attack, operators can use BGP itself to advertise rules that match certain packet characteristics and apply actions such as rate limiting or dropping traffic. In the right hands, FlowSpec is one of the more elegant defensive tools in the operator’s kit.That elegance is also why parser bugs in FlowSpec deserve attention. FlowSpec messages are rich, structured, and policy-heavy; they are not simple route announcements containing only a prefix and a next hop. They encode components, operators, and match semantics that the receiving implementation must parse precisely. Every extra bit of expressiveness becomes a little more attack surface.
The vulnerability description points to a crafted FlowSpec component, not generic BGP traffic. That narrows the exposure to deployments where an attacker can get such data processed by FRR’s BGP daemon. In many production environments, BGP sessions are authenticated, filtered, and limited to known peers. In too many smaller or hastily built networks, however, routing control planes are trusted more by habit than by design.
FlowSpec also tends to live in environments where the stakes are already high. It is used by service providers, hosting firms, DDoS mitigation platforms, enterprise WANs, and labs that mirror larger production architectures. Those are exactly the places where a service crash can ripple outward: routes withdraw, policies disappear, traffic shifts, monitoring alarms fire, and engineers begin asking whether the network is under attack or simply misconfigured.
The Exploit Story Is Not the Same as the Patch Story
There is no need to inflate this CVE into an internet-wide catastrophe. The public record describes a denial-of-service condition, and the known fix is a straightforward bounds correction. The NVD entry lists CISA enrichment with no reported exploitation at the time of publication, and the public details do not establish code execution. That should keep the discussion grounded.But “not catastrophic” is not the same as “unimportant.” A vulnerability can be operationally serious without being glamorous. The attacker’s goal in many real-world incidents is not to steal data from the router; it is to create uncertainty, interrupt connectivity, or force failover at the worst possible time.
The most dangerous misreading would be to say that because this is “only DoS,” it can wait. In routing infrastructure, DoS is often the whole point. If a crafted message can repeatedly crash
bgpd, an attacker may not need persistence inside the system to cause persistent harm. They only need a path to keep feeding the vulnerable component malformed input.There is also a subtler concern: parser bugs in control-plane software tend to test the assumptions of surrounding defenses. Operators often think in terms of BGP neighbor trust, TCP MD5 or TCP-AO protections, TTL security, prefix filters, and peer ACLs. Those controls are valuable, but they do not erase the need to patch implementation flaws. They reduce who can reach the parser; they do not make the parser safe.
Microsoft’s Appearance in the Story Is a Supply-Chain Signal
The user-facing source here is Microsoft’s Security Update Guide, which may seem odd for a vulnerability in FRRouting. That does not automatically mean Windows itself is vulnerable, nor does it mean every Microsoft customer has FRR deployed somewhere. It means Microsoft’s vulnerability ecosystem is tracking the issue, likely because modern cloud and enterprise stacks include many non-Windows components that matter to Microsoft customers.That is now normal. Azure, Windows Server estates, developer platforms, security products, virtual appliances, Linux workloads, and hybrid infrastructure all intersect. A Windows admin can be responsible for an environment where the critical routing component is not a Windows service at all. The old boundary between “Microsoft patching” and “Linux network package patching” has been dissolved by hybrid IT.
This is especially true in organizations that run Windows-heavy endpoints but Linux-heavy infrastructure. Active Directory, Entra ID, Windows Server, Hyper-V, SQL Server, and Intune may define the administrative center of gravity, while FRR or FRR-derived components quietly move traffic in a lab, container platform, virtual network appliance, or branch router. When that routing layer stumbles, Windows users experience it as an outage, not as a Linux issue.
The practical implication is that asset inventory needs to include routing software by name and version, not merely device model and operating system family. It is not enough to know that a box is “a router” or “a Linux appliance.” If FRR is present, teams need to know which branch, which package source, which vendor build, and whether FlowSpec is enabled or accepted from peers.
Debian’s Tracker Shows the Messy Middle of Open-Source Remediation
One of the more revealing details is the distribution-level status. Debian’s tracker lists multiple stable releases as vulnerable while newer unstable branches show fixes. That is not a scandal; it is how open-source remediation often looks in motion. A fix can exist upstream while downstream distributions, appliance vendors, and long-term-support channels move at different speeds.For administrators, that gap is where risk lives. The upstream project may have committed a patch. A distribution may have imported it into unstable. A vendor may still be testing a backport. An appliance image may lag behind both. A container image may never update unless the team rebuilds it. A lab VM may keep running the old package forever because nobody considers it production, right up until production depends on it.
FRR’s own versioning adds another layer. The CVE description calls out stable/10.0, while NVD’s configuration analysis identifies FRRouting 10.0. Debian’s package status reflects distro versions that do not map cleanly to upstream names in the way hurried scanners sometimes imply. That means vulnerability management teams should resist the urge to rely on a single string match.
The best approach is boring and effective: compare installed package versions against vendor advisories, inspect whether the relevant patch is present, and verify the behavior of your actual build. For source-built FRR, that means checking the commit history or applying the patch directly. For packaged FRR, that means waiting for and deploying the distribution’s security update rather than assuming an upstream tag tells the whole story.
The Windows Admin’s Exposure Is Often Indirect
Most Windows desktops are nowhere near this bug. Most Windows Server systems are not running FRR. But enterprise outages rarely respect product boundaries. If an FRR-based router in a lab, cloud VPC, hypervisor host, container node, or edge appliance falls over, Windows workloads behind it may lose connectivity just as surely as if the Windows systems themselves had crashed.This is why CVE-2026-37457 belongs in a WindowsForum discussion. The Windows estate is often the visible part of a larger dependency chain. Users notice when file shares pause, remote desktop sessions drop, VPN routes disappear, domain controllers become unreachable, or line-of-business applications time out. They do not care whether the root cause was a malformed FlowSpec component processed by a Linux routing daemon.
Hybrid environments make the issue more likely, not less. Many organizations now run Windows clients, Linux servers, cloud-managed firewalls, SD-WAN appliances, Kubernetes clusters, and virtual routers in a single operational fabric. FRR appears in open networking stacks precisely because it is capable and flexible. That same flexibility means it may be tucked into places the Windows team does not routinely patch.
There is a cultural problem here too. Windows patching has become process-heavy, calendar-driven, and audit-friendly. Network appliance patching is often more bespoke, more cautious, and more dependent on maintenance windows. Linux routing packages that sit between those worlds can fall through the cracks: not quite part of Patch Tuesday, not quite part of the network vendor’s firmware cycle, and not quite owned by the application team.
The Control Plane Needs the Same Discipline as the Endpoint Fleet
Endpoint security culture has trained administrators to ask familiar questions: Is the system exposed? Is the vulnerability remotely reachable? Is exploitation public? Is a patch available? Is there a workaround? Those questions apply just as well to routing daemons, but the operational answers are harder.For CVE-2026-37457, the first question is whether FRR is present and whether
bgpd is enabled. FRR can run multiple routing daemons, and not every installation uses BGP. A host with the package installed but no BGP daemon active is not in the same risk position as a router accepting BGP sessions that carry FlowSpec updates.The second question is whether FlowSpec is configured and from whom it is accepted. If FlowSpec is not in use, the reachable attack surface may be reduced, although administrators should be careful about assuming disabled features are never parsed in unexpected paths. If FlowSpec is accepted only from tightly controlled peers over protected sessions, the risk is different from a route server, lab, or poorly filtered edge that accepts more input than intended.
The third question is what happens when
bgpd dies. Some deployments will restart the daemon automatically. Some will withdraw routes. Some will preserve forwarding state for a time. Some will fail over cleanly. Some will create a brownout that is harder to diagnose than a total outage. A security advisory tells you the bug class; only your topology tells you the blast radius.This is where routing security becomes operational engineering. The patch is necessary, but so is a sober look at control-plane protection, peer filtering, monitoring, and failover behavior. A malformed FlowSpec component should not be able to become a business outage merely because one daemon accepted one bad object.
Memory Safety Is Still Networking’s Oldest Unpaid Debt
The uncomfortable part of CVE-2026-37457 is not that FRR had a bug. Mature, widely used C projects accumulate edge cases, especially in parsers for complex protocols. The uncomfortable part is that the networking world continues to rely on memory-unsafe components at exactly the places where availability failures are most visible.C remains dominant in routing stacks for good reasons: performance, portability, history, and deep integration with operating system networking internals. But those reasons do not make bounds errors disappear. They simply make defensive coding, fuzzing, code review, and rapid patch distribution non-negotiable.
Off-by-one errors are particularly revealing because they are rarely architectural failures. They are small mistakes with large consequences. A comparison operator, a maximum constant, and an array size fall out of alignment, and suddenly a control-plane parser can write past its intended storage. The fix may be one character, but the discipline required to find every similar edge case is much larger.
The industry’s move toward memory-safe languages will help in some domains, but routing stacks will not be rewritten overnight. In the meantime, the practical answer is layered: sanitize protocol input, fuzz decoders, restrict peers, monitor daemon stability, isolate control-plane services, and update aggressively when parser bugs land. None of that is novel. The problem is consistency.
Scanners Will Find the CVE Before They Understand the Network
By now, vulnerability scanners are likely to flag CVE-2026-37457 wherever they can identify affected FRR packages. That is useful, but it can also produce noisy results. A scanner may know that a package version is vulnerable without knowing whether BGP is enabled, whether FlowSpec is configured, whether the daemon is reachable, or whether a vendor backport has already landed without changing the upstream-looking version string.This is the familiar weakness of CVE-driven operations. The CVE is a starting point, not the final risk assessment. In a Windows-heavy enterprise, the scanner output may land on a security dashboard owned by one team, while the actual FRR instance is managed by a network team, a platform team, or an outsourced provider. The first challenge is not patching. It is ownership.
Administrators should expect some false certainty from tools. A package may appear vulnerable because the version string is old, even though the distro backported the patch. Conversely, a system may appear clean because the scanner lacks visibility into a container image, custom build, or appliance shell. Both errors are common enough that serious environments need verification beyond the dashboard.
That verification does not have to be heroic. Inventory the FRR instances. Check active daemons. Confirm package provenance. Review whether FlowSpec is enabled. Identify accepted BGP peers. Confirm whether the patch that changes the FlowSpec operator bounds check is present. Then test failover behavior under controlled conditions instead of discovering it during an incident.
A Small FRR Patch Exposes a Bigger Maintenance Contract
The concrete lessons from CVE-2026-37457 are not complicated, which is exactly why they are worth writing down. The danger is that a small patch invites a small response, when the better response is to use the bug as a reminder to tighten the routing software maintenance contract.- Organizations should identify every FRR deployment, including lab routers, virtual appliances, containers, cloud images, and vendor-managed systems that may not appear in normal Windows patch inventories.
- Administrators should verify whether
bgpdis active and whether BGP FlowSpec is enabled or accepted from any peer. - Teams should apply vendor or distribution updates that include the upstream bounds-check fix rather than assuming that a generic FRR version label tells the whole story.
- Network operators should restrict BGP and FlowSpec input to expected peers using control-plane ACLs, authentication where available, and conservative policy filters.
- Incident responders should treat repeated
bgpdcrashes as a potential control-plane attack signal, not merely as daemon instability. - Windows-focused IT teams should include routing software in dependency mapping, because Windows service availability can depend on non-Windows control-plane components.
The Real Severity Is Measured in Lost Reachability
CVSS gives CVE-2026-37457 a useful shorthand: high severity because availability can be hit remotely with low complexity and no privileges. But the real severity depends on topology. A vulnerable FRR instance in a lab is an inconvenience. A vulnerable FRR instance carrying production route policy for a hosting network, campus, branch fabric, or cloud edge can be a very different event.That is why this bug should be triaged by network role, not by package name alone. A route reflector, edge router, DDoS mitigation node, or FlowSpec controller deserves faster attention than a dormant package on a test VM. Conversely, a noisy scanner finding on an inactive host should not distract from a quieter but more exposed routing daemon in the path of production traffic.
Microsoft’s presence in the disclosure chain is a useful reminder of where enterprise infrastructure has gone. Windows administrators now live in ecosystems where Microsoft advisories, Linux packages, GitHub commits, Debian trackers, cloud images, and network control planes all describe different slices of the same operational reality. A security program that only patches what appears in Windows Update is no longer patching the estate.
CVE-2026-37457 will probably not be remembered as one of the defining vulnerabilities of 2026. It is too narrow, too fixable, and too short on spectacle. But it is a clean example of a more durable truth: modern availability failures often begin as tiny parser mistakes in components nobody sees until they stop working. The organizations that handle this well will not be the ones with the loudest dashboards; they will be the ones that know where their routing software runs, who owns it, and how quickly a one-character fix can move from upstream code into the path their users depend on.
References
- Primary source: MSRC
Published: 2026-06-03T01:45:17-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: sentinelone.com
CVE-2026-37457: FRRouting (FRR) DoS Vulnerability
CVE-2026-37457 is a denial of service vulnerability in FRRouting (FRR). Learn about its impact, affected versions, and mitigation methods.www.sentinelone.com
- Related coverage: thehackerwire.com
CVE-2026-37457 - High Vulnerability
CVE-2026-37457 is a High severity vulnerability (CVSS 7.5). An off-by-one out-of-bounds write vulnerability in the bgp_flowspec_op_decode() function (bgpd/bgp_flowspec_util.c) of FRRouting (FRR) stable/10.0 allows attackers to cause a Denial...www.thehackerwire.com
- Related coverage: docs.frrouting.org
- Related coverage: datatracker.ietf.org
