CVE-2023-20269

Published Sep 6, 2023

Last updated 8 months ago

Exploit knownCVSS medium 5.0
Cisco ASA
SSL

Overview

AI description

Automated description summarized from trusted sources.

CVE-2023-20269 is a vulnerability found in the remote access VPN feature of Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software. It stems from improper separation of authentication, authorization, and accounting (AAA) between the remote access VPN feature and the HTTPS management and site-to-site VPN features. The vulnerability can be exploited in two ways: an unauthenticated, remote attacker could conduct a brute force attack to identify valid username and password combinations, or an authenticated, remote attacker could establish a clientless SSL VPN session with an unauthorized user. Exploitation may require specific conditions, such as having at least one user configured with a password in the local database or having HTTPS management authentication pointing to a valid AAA server. In the latter case, the attacker needs valid credentials. This vulnerability is actively being exploited by ransomware groups.

Description
A vulnerability in the remote access VPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to conduct a brute force attack in an attempt to identify valid username and password combinations or an authenticated, remote attacker to establish a clientless SSL VPN session with an unauthorized user. This vulnerability is due to improper separation of authentication, authorization, and accounting (AAA) between the remote access VPN feature and the HTTPS management and site-to-site VPN features. An attacker could exploit this vulnerability by specifying a default connection profile/tunnel group while conducting a brute force attack or while establishing a clientless SSL VPN session using valid credentials. A successful exploit could allow the attacker to achieve one or both of the following: Identify valid credentials that could then be used to establish an unauthorized remote access VPN session. Establish a clientless SSL VPN session (only when running Cisco ASA Software Release 9.16 or earlier). Notes: Establishing a client-based remote access VPN tunnel is not possible as these default connection profiles/tunnel groups do not and cannot have an IP address pool configured. This vulnerability does not allow an attacker to bypass authentication. To successfully establish a remote access VPN session, valid credentials are required, including a valid second factor if multi-factor authentication (MFA) is configured. Cisco will release software updates that address this vulnerability. There are workarounds that address this vulnerability.
Source
psirt@cisco.com
NVD status
Analyzed
Products
adaptive_security_appliance_software, firepower_threat_defense

Risk scores

CVSS 3.1

Type
Primary
Base score
9.1
Impact score
5.2
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Severity
CRITICAL

Known exploits

Data from CISA

Vulnerability name
Cisco Adaptive Security Appliance and Firepower Threat Defense Unauthorized Access Vulnerability
Exploit added on
Sep 13, 2023
Exploit action due
Oct 4, 2023
Required action
Apply mitigations per vendor instructions for group-lock and vpn-simultaneous-logins or discontinue use of the product for unsupported devices.

Weaknesses

psirt@cisco.com
CWE-288
nvd@nist.gov
CWE-863

Social media

Hype score
Not currently trending

  1. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2021-27876 (Veritas Veritas..) +273.78% - CVE-2022-24521 (CLFS..) +238.29% - CVE-2021-27878 (Veritas Veritas..) +163.49% - CVE-2023-27351 (PaperCut Applic..) +95.65% - CVE-2023-20269 (ASA..) +82.95%

    @DefusedCyber

    22 Nov 2025

    2032 Impressions

    1 Retweet

    12 Likes

    5 Bookmarks

    1 Reply

    1 Quote

  2. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2021-27877 (Veritas Veritas..) +934.92% - CVE-2025-29824 (CLFS..) +289.16% - CVE-2021-30116 (Kaseya VSA..) +223.20% - CVE-2022-24521 (CLFS..) +208.83% - CVE-2023-20269 (ASA..) +168.29%

    @DefusedCyber

    11 Nov 2025

    1497 Impressions

    1 Retweet

    13 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

  3. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2025-61882 (Oracle E-Busine..) +186086.05% - CVE-2021-27877 (Veritas Veritas..) +879.54% - CVE-2023-20269 (ASA..) +302.13% - CVE-2023-20269 (FTD..) +302.13% - CVE-2025-29824 (CLFS..) +289.16%

    @DefusedCyber

    3 Nov 2025

    12360 Impressions

    14 Retweets

    55 Likes

    13 Bookmarks

    1 Reply

    1 Quote

  4. 🔴 #Cisco ASA & FTD, Remote Code Execution, #CVE-2023-20269 (Critical) https://t.co/i4xn3Dtj9O

    @dailycve

    25 Sept 2025

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2015-2291 (IQVW32.sys (BYO..) +23.34% - CVE-2024-26169 (Windows Error R..) +9.58% - CVE-2023-20269 (ASA..) +6.84% - CVE-2023-20269 (FTD..) +6.84% - CVE-2022-27510 (NetScaler ADC..) +6.76%

    @DefusedCyber

    15 Sept 2025

    8370 Impressions

    10 Retweets

    79 Likes

    38 Bookmarks

    1 Reply

    1 Quote

  6. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2025-53770 (SharePoint..) +25.40% - CVE-2023-20269 (ASA..) +24.24% - CVE-2023-20269 (FTD..) +24.24% - CVE-2024-26169 (Windows Error R..) +9.58% - CVE-2022-27510 (NetScaler ADC..) +6.76%

    @DefusedCyber

    8 Sept 2025

    5121 Impressions

    9 Retweets

    43 Likes

    18 Bookmarks

    2 Replies

    2 Quotes

  7. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2025-53770 (SharePoint..) +361.94% - CVE-2024-42057 (Zyxel Firewall..) +29.73% - CVE-2023-20269 (ASA..) +24.24% - CVE-2023-20269 (FTD..) +24.24% - CVE-2021-21974 (ESXi..) +16.07%

    @DefusedCyber

    25 Aug 2025

    936 Impressions

    1 Retweet

    14 Likes

    5 Bookmarks

    0 Replies

    1 Quote

  8. Ransomware vulns with highest exploit likelihood ⬆️ (past 30d): - CVE-2025-53770 (SharePoint..) +108108.75% - CVE-2023-20269 (ASA..) +58.41% - CVE-2023-20269 (FTD..) +58.41% - CVE-2024-42057 (Zyxel Firewall..) +29.73% - CVE-2024-37085 (ESXi..) +20.63%

    @DefusedCyber

    18 Aug 2025

    20187 Impressions

    30 Retweets

    184 Likes

    111 Bookmarks

    2 Replies

    1 Quote

Configurations

Related CVEs

  1. Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) mishandle the authentication of AAD (Additional Authenticated Data) with an empty ciphertext allowing a forgery of such messages. Impact summary: An attacker can forge empty messages with arbitrary AAD to the victim's application using these ciphers. AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD modes: they accept a key, nonce, optional AAD (bytes that are authenticated but not encrypted), and plaintext, and produces ciphertext plus a 16-byte tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only if the tag is verified succesfully. In OpenSSL's provider implementation of these ciphers, the expected tag is computed only when decryption function is invoked with non-empty data. If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without invocation of the ciphertext update, which can happen when the received ciphertext length is zero, the tag is never recalculated and still holds its all-zeros value. When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty ciphertext, and all-zeros tag passes authentication under any key they do not know, single-shot. When AES-SIV is used, for mounting the attack it's necessary for the application to reuse the decryption context without resetting the key. AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since OpenSSL 3.2. No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must implement their own protocol and use the EVP interface. Also they must skip the ciphertext update when a message with an empty ciphertext arrives. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as these algorithms are not FIPS approved and the affected code is outside the OpenSSL FIPS module boundary.•CVE-2026-45446
  2. Issue summary: A specially crafted PKCS#7 or S/MIME signed message could trigger a use-after-free during PKCS#7 signature verification. Impact summary: A use-after-free may result in process crashes, heap corruption, or potentially remote code execution. When processing a PKCS#7 or S/MIME signed message, if the SignedData digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent use of the BIO by the calling application results in a use-after-free condition. In the common case this occurs when the application later calls BIO_free() on the BIO originally passed to PKCS7_verify(). Depending on allocator behavior and application-specific BIO usage patterns, this may result in a crash or other memory corruption. In some application contexts this may potentially be exploitable for remote code execution. Applications that process PKCS#7 or S/MIME signed messages using OpenSSL PKCS#7 APIs may be affected. Applications using the CMS APIs for this processing are not affected. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.•CVE-2026-45447
  3. Issue summary: When an application drives an AES-OCB context through the public EVP_Cipher() one-shot interface, the application-supplied initialisation vector (IV) is silently discarded. Impact summary: Every message encrypted under the same key uses the same effective nonce regardless of the IV supplied by the caller, resulting in (key, nonce) reuse and loss of confidentiality. If the same code path is used to compute the authentication tag, the tag depends only on the (key, IV) pair and not on the plaintext or ciphertext, allowing universal forgery of arbitrary ciphertext from a single captured message. OpenSSL provides two ways to drive a cipher: the documented streaming interface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level one-shot, EVP_Cipher(), whose documentation explicitly recommends against use by applications in favour of EVP_CipherUpdate() and EVP_CipherFinal_ex(). The OCB provider's streaming handler flushes the application-supplied IV into the OCB context before processing data; the one-shot handler did not. Every call to EVP_Cipher() on an AES-OCB context therefore ran with the all-zero key-derived offset state left by cipher initialisation, regardless of the caller's IV. If EVP_EncryptFinal_ex() is subsequently used to obtain the authentication tag, the deferred IV setup runs at that point and clears the running checksum that should have been accumulated over the plaintext. The resulting tag is a function of (key, IV) only and verifies against any ciphertext produced under the same (key, IV) pair. The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a TLS cipher suite, and libssl does not call EVP_Cipher() in any case. Applications that drive AES-OCB through the documented streaming AEAD API (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Only applications that combine the AES-OCB cipher with the EVP_Cipher() one-shot API are vulnerable. The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by this issue, as AES-OCB is outside the OpenSSL FIPS module boundary.•CVE-2026-45445
  4. Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the peer key is not properly checked for the subgroup membership. Impact summary: A malicious peer which presents an X9.42 key carrying the victim's p and g parameters, a forged q = r (a small prime factor of the cofactor (p−1)/q_local), and a public value Y of order r can recover the victim's private key after a small number of key exchange attempts. When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's own q parameter, not the local key's q. The peer's domain parameters are then matched against the domain parameters of the private key, but the value of q is not compared. A malicious peer who presents an X9.42 key carrying the victim's p, g, a forged q = r (a small prime factor of the cofactor), and a public value Y of order r passes all checks. The shared secret then takes only r distinct values, leaking priv mod r. Repeating for each small-prime factor of the cofactor and combining via CRT recovers the full private key (Lim–Lee / small-subgroup-confinement attack). The realistic attack surface is narrow: principally CMP deployments with long-lived RA/CA DHX keys and bespoke enterprise or government applications using X9.42 DHX static keys with interactive protocols and therefore this issue was assigned Low severity. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are affected by this issue.•CVE-2026-42770
  5. Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to Bleichenbacher-style attack when an attacker is able to provide the CMS or S/MIME messages and observe the error code and/or decryption output. Impact summary: The Bleichenbacher-style attack allows an attacker to use the victim's vulnerable application as a way to decrypt or sign messages with the victim's private RSA key. The attack is possible in 2 variants. 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without providing the recipient certificate. In this case OpenSSL iterates over every KeyTransRecipientInfo (KTRI) without stopping at the first success. An attacker who authors a message with two KTRI entries — the first one wrapping a real CEK under the victim's public key, the second with an arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to get a valid PKCS#1 v1.5 padding if the error code of the application is available. That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an adaptive-chosen-ciphertext side channel from which the attacker decrypts any RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under it. 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with the recipient certificate, and the recipient is not found, a random key is substituted. An attacker who authors a message and is able to compare both error code and the result of the decryption, can mount a Bleichenbacher oracle. We are not aware of any applications that provide a remote attacker an opportunity to mount an attack described in these scenarios. We consider the existence of such application very unlikely, and for this reason this CVE has been evaluated as Low severity. To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit rejection was explicitly disabled. The implicit rejection mechanism always returns a plaintext value, the symmetric key. This result is deterministic for the ciphertext and the private key. The length of the decryption result can happen to match the length of the key of the symmetric cipher that was used for the content encryption. When a certificate is not provided, the last RecipientInfo producing a key that looks valid will be used. It may cause getting garbage content on decryption. As a proper way to deal with this a recipient certificate has to be provided to identify the particular RecipientInfo for decryption. The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.•CVE-2026-42768

References

Sources include official advisories and independent security research.