MEDIUM 5.9

CVE-2026-57030: Juniper SRX Race Condition DoS Vulnerability

Juniper SRX Series firewalls contain a race condition in their packet forwarding engine that can be exploited by sending specially crafted network traffic to cause denial of service. The bug occurs during flow session cleanup—normally flows are removed after 3 seconds of inactivity, but a timing issue can cause the timeout to be set to over 10,000 seconds instead. This prevents flows from being cleaned up properly, causing session tables to accumulate stale entries until the device either stops forwarding traffic entirely or crashes and reboots.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.9 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-362
Affected products
34 configuration(s)
Published / Modified
2026-07-09 / 2026-07-13

NVD description (verbatim)

A Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS). As part of the stateful traffic processing on SRX Series devices flows are being established, and removed when not needed anymore. During the removal process the timeout of a flow should be set to 3 seconds and consequentially the flow should be removed shortly after. Due to a race condition occurring when setting the timeout there is a chance (the exact conditions are outside the attackers control) that the timeout is instead set to a very high value of larger than 10,000 seconds: user@host> show security flow session | match timeout Session ID: 98784248524, Policy name: PROD-FLOW/4, HA State: Active, Timeout: 85250, Session State: Valid This will lead to an accumulation of flows which can be observed by an ever-increasing value of invalidated sessions in the output of 'show security flow session summary': user@host> show security flow session summary | match invalid Invalidated sessions: 216931These sessions can't be cleared manually with the 'clear security flow session' command, which will either lead to forwarding to stop (and the system needs to be manually recovered with a reboot) or to a flowd core and automatic reboot. This issue affects Junos OS on SRX Series: * 24.2 versions before 24.2R2-S3, * 24.4 versions before 24.4R2-S1, 24.4R2-S2, * 25.2 versions before 25.2R1-S2, 25.2R2. This issue does not affect releases earlier than 24.2R1;

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-57030 is a race condition (CWE-362) in the Junos OS packet forwarding engine (PFE) affecting SRX Series stateful inspection devices. During flow session removal, improper synchronization when setting flow timeouts can result in the timeout value being set to >10,000 seconds instead of the intended 3 seconds. This leads to accumulated invalid sessions visible in 'show security flow session summary' output. The accumulation of uncleared sessions eventually exhausts forwarding resources, triggering either complete forwarding halt or a flowd process crash with automatic device reboot. The vulnerability requires network access but no authentication or user interaction; exploitation is probabilistic due to the race condition's unpredictable nature.

Business impact

Organizations running Juniper SRX firewalls face potential network outages when this vulnerability is triggered. The impact ranges from gradual performance degradation and session table exhaustion to complete loss of firewall forwarding functionality. Affected organizations may experience unplanned downtime requiring manual device recovery or reboot, disrupting all traffic inspection and security policy enforcement. For critical security infrastructure relying on SRX devices for perimeter defense or internal traffic segmentation, this represents a material availability risk.

Affected systems

The vulnerability affects Juniper Junos OS running on SRX Series devices. Specific affected versions include: 24.2 releases before 24.2R2-S3; 24.4 releases before 24.4R2-S1 and 24.4R2-S2; and 25.2 releases before 25.2R1-S2 and 25.2R2. Releases earlier than 24.2R1 are not affected. This covers a broad range of SRX hardware models including the SRX300, SRX320, SRX340, SRX345, SRX380, SRX400, SRX440, SRX1500, SRX1600, SRX2300, SRX4100, SRX4120, SRX4200, SRX4300, SRX4600, SRX4700, SRX5400, SRX5600, and SRX5800.

Exploitability

Exploitation requires only network access and no authentication credentials. However, the CVSS score of 5.9 (MEDIUM) reflects an important constraint: the race condition's timing is outside the attacker's direct control, making reliable exploitation probabilistic rather than deterministic. An attacker would need to send traffic patterns that coincidentally trigger the timeout-setting race window, but given that SRX devices continuously process flows in production environments, opportunities for collision should arise with reasonable frequency under sustained traffic. This is not a trivial one-packet exploit; rather, it represents a DoS vector that becomes increasingly likely with higher traffic volumes or specific flow churn patterns.

Remediation

Juniper has released patched versions addressing this race condition. Organizations should upgrade to: Junos OS 24.2R2-S3 or later for the 24.2 branch; 24.4R2-S1, 24.4R2-S2, or later for the 24.4 branch; or 25.2R1-S2, 25.2R2, or later for the 25.2 branch. Verify exact patch availability against Juniper's security advisory before deployment. Interim mitigations such as flow session monitoring and manual flow clearing may help detect problems early, but complete remediation requires patching. Organizations unable to patch immediately should prioritize SRX devices in high-traffic or critical-path positions for upgrade scheduling.

Patch guidance

Consult Juniper's official security advisory for the exact patched version numbers and download links applicable to your deployment. Patches are available for 24.2, 24.4, and 25.2 branches. Standard Junos OS upgrade procedures apply: schedule maintenance windows, back up configurations, test patches in non-production environments if possible, and monitor device stability post-upgrade. High-availability SRX clusters should coordinate upgrades to maintain redundancy. Given the probabilistic nature of the vulnerability and its potential for unplanned reboot, patching should be prioritized within normal change windows rather than waiting for emergency hotfix cycles.

Detection guidance

Monitor SRX devices for accumulating invalidated sessions using 'show security flow session summary | match invalid'. A rising trend in invalidated sessions without corresponding clearing may indicate exposure to this race condition. Additionally, watch for unexpected flowd process crashes, automatic device reboots, or forwarding halts correlated with high flow churn or unusual traffic patterns. Flow session timeout anomalies (timeouts >10,000 seconds visible via 'show security flow session') are a direct indicator. Correlate SRX logs and syslog output for flowd restarts or core dumps. Organizations should establish baseline flow session counts and alert on anomalous growth.

Why prioritize this

Although rated MEDIUM severity, this vulnerability merits prompt prioritization because it affects critical security infrastructure (SRX firewalls), can cause unplanned downtime, and is triggered by ordinary network traffic patterns without requiring exploitation sophistication. For organizations where SRX devices handle mission-critical traffic inspection, the business impact of an unplanned reboot justifies accelerated patch scheduling. The probabilistic nature of the race condition means that patching is more practical than attempting to avoid triggering it through traffic engineering.

Risk score, explained

The CVSS 3.1 score of 5.9 reflects high attack complexity (AC:H) due to the race condition's unpredictable timing, combined with high availability impact (A:H) and network-based attack vector (AV:N) requiring no authentication. The score appropriately captures that exploitation is feasible but not trivial, and the impact—denial of service causing potential device unavailability—is severe but limited to availability rather than affecting confidentiality or integrity.

Frequently asked questions

Can this vulnerability be exploited remotely without sending malicious packets?

No. Exploitation requires network-based traffic that happens to trigger a race condition during flow timeout processing. An attacker cannot exploit this from outside the network path traversed by the SRX device. However, ordinary traffic flowing through the device creates opportunities for the race window to align; sustained or high-volume traffic increases the statistical likelihood of collision.

Will my SRX device crash immediately after this vulnerability is triggered?

Not necessarily. The vulnerability causes flows to accumulate with incorrect long timeouts, gradually exhausting the flow session table. The device may experience progressive performance degradation before hitting a breaking point—either complete forwarding halt or a flowd crash. The timing varies based on traffic volume and patterns.

Can I work around this vulnerability without patching?

No complete workaround exists, though you can monitor for symptoms and manually intervene if necessary. Monitoring 'show security flow session summary' for rising invalidated session counts can provide early warning, but manual flow clearing is ineffective against this issue. Patching is the only reliable remediation.

Does this affect SRX devices running releases before 24.2R1?

No. Juniper confirmed that releases earlier than 24.2R1 are not affected. If your devices are on 24.1 or earlier, this vulnerability does not apply, though you should verify your exact version via 'show version' or the CLI.

This analysis is provided for informational purposes and should not be considered a substitute for vendor advisories or professional security guidance. Organizations should verify all patch version numbers and affected product models directly against Juniper's official security advisory before taking remediation actions. The vulnerability's probabilistic exploitability does not diminish its potential impact; network defenders should apply patches systematically rather than assuming their devices will not encounter the race condition. SEC.co makes no guarantee of exploit availability, active exploitation in the wild, or timeline for KEV listing. Always test patches in non-production environments before broad deployment. Source: NVD (public-domain), retrieved 2026-08-17. Analysis generated by SEC.co (claude-haiku-4-5).