CVE-2026-20349: Cisco Firewall Flaw Actively Exploited for DoS

Published on 17 August 2026

A single, cleverly crafted network request is enough to bring a Cisco firewall to its knees – and attackers are already exploiting exactly that. With CVE-2026-20349, Cisco has confirmed a security vulnerability in its widely deployed firewall products Secure Firewall ASA and Secure Firewall Threat Defense (FTD). Via the remote-access VPN service (remote-access SSL VPN), an attacker can force a vulnerable appliance into an unexpected reboot without any authentication whatsoever. The result: VPN access drops out, and in the worst case the entire network perimeter goes down. Cisco is providing hotfixes – there is no workaround.

What happened?

Cisco published the security advisory for CVE-2026-20349 on 11 August 2026. Shortly afterwards, also on 11 August, the US security agency CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue (KEV catalogue) – explicitly "based on evidence of active exploitation," that is, on the basis of evidence of active attacks in the wild.

The Cisco Product Security Incident Response Team (PSIRT) confirms the ongoing attacks unmistakably:

"In August 2026, the Cisco Product Security Incident Response Team (PSIRT) became aware of active exploitation of this vulnerability. Cisco strongly recommends that customers upgrade to a fixed software release to remediate this vulnerability." – Cisco PSIRT

The Canadian Centre for Cyber Security also confirms the active exploitation in its Alert AL26-018 of 13 August 2026. This is therefore not a theoretical threat, but a vulnerability that is already being abused right now.

Important for context: the primary damage is a Denial of Service (DoS) – that is, an availability outage caused by a forced reboot. As things currently stand, this vulnerability is not about data theft or bypassing authentication. Cisco explicitly rates the impact on confidentiality and integrity as "None," but the impact on availability as "High."

Technical background – explained clearly

A firewall such as the Cisco ASA or FTD sits at the boundary between the internet and the internal corporate network. Many companies additionally use these devices as a VPN gateway – that is, as a dial-in point through which employees can securely connect to the corporate network while on the move. It is precisely this remote-access service that serves as the entry point.

According to Cisco, the vulnerability lies in insufficient error checking during the processing of HTTP requests (the technical category is CWE-244). An attacker can send a specially crafted HTTP request – that is, a deliberately manipulated web request – to the remote-access SSL VPN service. The appliance processes this request incorrectly and reboots unexpectedly (a so-called "reload"). During this reboot, the device is unavailable.

The attack is particularly dangerous because it:

• is carried out over the network (no physical access needed),
• requires no credentials (unauthenticated),
• requires no user interaction (nobody has to click on anything),
• and is technically low in complexity.

The official CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H and produces a severity rating of 8.6 out of 10 (High).

Security researcher Igal Zeifman of CyCognito sums up the real gravity of the matter:

"Because the affected devices are firewalls and VPN concentrators, a successful exploit removes both the perimeter enforcement point and the remote access path for users at the same time." – Igal Zeifman, CyCognito

In essence: since the affected devices are firewall and VPN concentrator at the same time, a successful attack removes both the protective network perimeter and the users' remote-access path in one fell swoop.

Who is affected?

An appliance is only affected when two conditions come together: first, a vulnerable software version must be running. Second, at least one of the relevant remote-access functions must be enabled that opens a so-called SSL listen socket – that is, a service that listens for incoming encrypted connections from the internet.

Vulnerable software versions:

• Cisco Secure Firewall ASA: 9.16, 9.18, 9.20, 9.22, 9.23 and 9.24
• Cisco Secure Firewall FTD: 7.0, 7.2, 7.4, 7.6, 7.7 and 10.0

Relevant enabled functions:

• IKEv2 Remote Access VPN with Client Services (configuration pattern: crypto ikev2 enable <interface_name> client-services port <port_numbers>)
• SSL VPN (WebVPN) (configuration pattern: webvpn with enable <interface_name>)
• on FTD, additionally ZTNA (Zero Trust Network Access, configuration pattern: zero-trust / enable)

Good news for some users: the Secure Firewall Management Center (FMC) is, according to Cisco, not affected. If a vulnerable version is running but none of the mentioned functions is active, the device likewise does not meet the configuration condition.

And one more clear distinction for small and medium-sized enterprises: anyone who operates no Cisco ASA or FTD firewall at all is not directly affected by this specific vulnerability. What matters, however, is that you actually know this for certain – especially if your IT infrastructure is partly or entirely outsourced.

How to check whether you are affected

1. Create an inventory. Immediately record all Cisco Secure Firewall ASA and FTD appliances operated by you or by service providers. For each device, note: model, serial number, management form, location, public IP/FQDN, responsible team, and whether it provides remote access. Do you not operate any Cisco firewall yourself? Then ask your hoster, managed service provider (MSP) and VPN service provider in writing about ASA/FTD remote-access instances in your tenant.
2. Determine the running version. Establish the ASA or FTD release version that is actually running. Cisco provides its Software Checker for this purpose – there you can select product, platform and release, or paste in the output of the show version command. Check the running state of each individual HA member (in redundantly designed systems), not just a planned target version.
3. Check functions. Verify whether one of the three relevant functions is active. On ASA, show running-config displays the mentioned patterns. On FTD, check remote access in the FMC under Devices > VPN > Remote Access or in the FDM under Remote Access VPN as well as ZTNA.
4. Check reachability from the internet. Establish whether the associated SSL services are reachable from the internet – for instance via the known public VPN URL, firewall rules and DNS entries. Do not carry out your own attack test with crafted requests while doing so.
5. Cross-check with Cisco. Compare release, platform and enabled function against Cisco's advisory and the Software Checker. In the event of a match, treat the device as high-priority vulnerable – the active exploitation is confirmed, and there is no workaround.
6. Review logs. Evaluate firewall, VPN, syslog and monitoring data since the beginning of August 2026 for unexpected reboots, failover events, service interruptions and suspicious HTTP requests against the remote-access service. Cisco does not publish specific indicators (IOCs); unexplained reloads are therefore grounds for investigation, but not sole proof. Preserve relevant logs and crash dumps in a forensically sound manner.

What you need to do now

Because active attacks are confirmed and there is no workaround, the controlled deployment of the correct Cisco hotfix is the central measure. Cisco provides the updates via the Cisco Software Center.

ASA target versions of the hotfixes (depending on branch): 89.16.4.50, 89.18.4.50, 9.20.4.235, 9.22.3.191, 9.23.1.211 and 9.24.1.221.

FTD target states: 7.0.9.1, 7.2.11.1, 7.4.7.1, 7.6.4.1, 7.7.11.1 and 10.0.0.1.

1. Patch by priority. Update all confirmed, internet-exposed ASA/FTD instances with a relevant function enabled, prioritising the hotfix intended for the branch and platform. Plan and test the procedure with your Cisco partner or the Cisco TAC – especially with high-availability setups, so that both nodes do not fail simultaneously.
2. Verify after the update. On each node, check the fixed version that is actually running and the restoration of VPN, ZTNA, routing, monitoring and HA. Document the time, device, before/after version, package hash per the vendor's specification, test result and rollback plan.
3. No patch substitute via makeshift solutions. Cisco explicitly names no workaround. If immediate patching is not possible, a time-limited reduction of the attack surface – such as disabling unneeded remote-access functions or restricting reachability to legitimate source networks – can shrink the attack space. This can, however, impair business operations and does not eliminate the vulnerability.
4. Public VPN gateways first. The Canadian Centre for Cyber Security explicitly recommends identifying internet-accessible ASA/FTD systems with remote access, remediating exposed systems as a priority, and monitoring gateway logs for disruptions as well as attempted exploitation.
5. Use detection. Cisco links to Snort Rules 46897 and 59654 – check and activate these according to your change process. Add alerts for unexpected reloads, failovers and the loss of VPN endpoints. Detection, however, does not reduce the vulnerability and does not replace the hotfix.
6. Clarify responsibilities. Clearly note whether an external MSP, hoster or corporate network operator is responsible for patching – and demand written proof of the fixed version state.

Context and GDPR relevance

CISA has entered 14 August 2026 as the deadline (dueDate) in the KEV catalogue. Important for German companies: this deadline applies to US federal agencies (BOD 26-04) and is not a directly applicable German legal deadline. It is, however, a clear signal of urgency – the authorities assess the threat as high and acute.

An unpatched vulnerability is not automatically a reportable data breach. The European Data Protection Board (EDPB) makes it clear: not every security incident is at the same time a breach of the protection of personal data. In the event of a DoS that has actually occurred, however, the controller must assess in a documented manner whether personal data was affected and whether this is likely to give rise to a risk to the rights and freedoms of natural persons.

Relevant here are above all:

• Art. 32 GDPR requires risk-adequate measures – explicitly including the ongoing ability to ensure the availability and resilience as well as a rapid restoration following a technical incident.
• Art. 33 GDPR: if a data breach with likely risk exists, it must be reported to the supervisory authority without undue delay, if possible within 72 hours. All data breaches must be documented.
• Art. 34 GDPR: in the case of a likely high risk, affected individuals must be notified without undue delay.

The fine framework under Art. 83(4) GDPR for breaches of obligations arising from Arts. 25 to 39 extends to up to €10 million or 2% of the worldwide annual turnover – whichever amount is higher. For context: in 2019 the BfDI imposed a fine of €9.55 million on 1&1 Telecom for, in the authority's view, inadequate technical and organisational measures under Art. 32 GDPR. That case, however, concerned telephone-based customer authentication, not a firewall vulnerability, and does not establish any fine as a consequence for CVE-2026-20349 – it merely shows how seriously appropriate security measures are taken. This assessment is not legal advice; in a concrete incident you should involve your data protection officer and, where appropriate, specialised legal counsel.

What the numbers do (not) say

A reliable public overall figure for vulnerable installations, affected German companies or affected data records has so far been published by none of the official sources (Cisco, CISA, Canadian Cyber Centre). For its – not further quantified – observation set, CyCognito cites industry shares of 27.0% industrial, 14.2% consumer goods and 12.7% IT. Without a known population, however, this is not a statistic that can be extrapolated for the German market.

Conclusion

CVE-2026-20349 is a serious, actively exploited vulnerability with a simple but effective attack pattern: an unauthenticated request, a forced reboot, a downed VPN gateway. For SMEs with an internet-exposed Cisco ASA or FTD appliance at a vulnerable state and with remote access active, the risk is high and time-critical. The likely damage is admittedly "only" an outage – but an outage of the network perimeter and remote access can bring down website operation, remote maintenance, cloud access, customer support and inventory management.

So act now: get clarity about your devices, check the version and enabled functions, and deploy the appropriate Cisco hotfix in a controlled manner. If you use outsourced infrastructure, demand written proof of the fixed version state. Anyone who does not operate a Cisco ASA or FTD firewall is not directly affected by this vulnerability – but should, precisely for that reason, make sure that this assumption really holds true.