CVE-2023-27997

Published Jun 13, 2023

Last updated 8 months ago

Exploit knownCVSS critical 9.8
Xortigate
Fortinet
web application
SSL
VPN
Port (443)

Overview

AI description

Automated description summarized from trusted sources.

CVE-2023-27997 is a heap-based buffer overflow vulnerability found in the SSL-VPN component of Fortinet's FortiOS and FortiProxy. It arises from the SSL-VPN pre-authentication module, where an overflow of data from an allocated memory block into adjacent memory blocks in the heap can occur. Successful exploitation of this vulnerability allows a remote attacker to execute arbitrary code or commands via specifically crafted requests. This can be achieved without authentication, potentially bypassing multi-factor authentication, and allowing attackers to access networks and products protected by the secure channel.

Description
A heap-based buffer overflow vulnerability [CWE-122] in FortiOS version 7.2.4 and below, version 7.0.11 and below, version 6.4.12 and below, version 6.0.16 and below and FortiProxy version 7.2.3 and below, version 7.0.9 and below, version 2.0.12 and below, version 1.2 all versions, version 1.1 all versions SSL-VPN may allow a remote attacker to execute arbitrary code or commands via specifically crafted requests.
Source
psirt@fortinet.com
NVD status
Analyzed
Products
fortiproxy, fortios

Risk scores

CVSS 3.1

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

Known exploits

Data from CISA

Vulnerability name
Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow Vulnerability
Exploit added on
Jun 13, 2023
Exploit action due
Jul 4, 2023
Required action
Apply updates per vendor instructions.

Weaknesses

psirt@fortinet.com
CWE-122
nvd@nist.gov
CWE-787

Social media

Hype score
Not currently trending

  1. CISA orders feds: Patch exploited Fortinet EMS flaw (CVE-2023-27997) by Friday or isolate. Actively hacked in wild—9.6 CVSS remote code exec. Enterprise wake-up call. https://t.co/xpDj963T03

    @thecircuitry_

    6 Apr 2026

    34 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. 336K FortiGate SSL VPNs still unpatched for CVE-2023-27997 (9.8) — unauth RCE, exploited in the wild. Patch/upgrade now, restrict SSL VPN exposure, and review configs for changes. https://t.co/12sSHRqRMu

    @Anavem_

    26 Jan 2026

    124 Impressions

    1 Retweet

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. Vulnérabilité dans les produits Fortinet (13 juin 2023) — Le 12 juin 2023, Fortinet a publié un avis de sécurité concernant la vulnérabilité CVE-2023-27997. Celle-ci permet à un attaquant non authentifié d'exécuter du code arbitraire à distance sur des produits Forti

    @RotateKeys

    5 Nov 2025

    3 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. Actor exploiting CVE-2023-27997 (Fortinet buffer overflow) from 170.247.220.25 🇺🇸 ( My Tech ) VirusTotal Detections: 0/95 🟢 This actor was recently mass probing Palo Alto devices for authentication pathways 🍯 https://t.co/IKexYhB9Eh

    @DefusedCyber

    31 Oct 2025

    4259 Impressions

    4 Retweets

    24 Likes

    6 Bookmarks

    0 Replies

    1 Quote

  5. Threat actors exploited Fortinet SSL-VPN CVEs (CVE-2022-42475, CVE-2023-27997, CVE-2024-21762) for unauthenticated remote code execution on FortiGate devices. Darktrace blocked intrusions via Autonomous Response. #Fortinet #NetworkAttack #USA https://t.co/jW17u7M9Wg

    @TweetThreatNews

    15 Aug 2025

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. Fortinet SSL-VPN vulnerabilities CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762 exploited for unauthenticated remote code execution, credential abuse, and RDP access. Autonomous Response helped contain the attack. #FortinetVPN #RemoteAccess #USA https://t.co/56lhxEhzZx

    @TweetThreatNews

    15 Aug 2025

    14 Impressions

    0 Retweets

    0 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  7. ⚡ Even patching won't save you. Fortinet confirms attackers kept read-only access to FortiGate devices after patching old flaws (CVE-2022-42475, CVE-2023-27997, CVE-2024-21762) via hidden symlink in SSL-VPN. https://t.co/gqXSmXNMa4

    @achi_tech

    19 Apr 2025

    103 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. Fortinet Releases Advisory on New Post-Exploitation Technique for Known Vulnerabilities: Fortinet is aware of a threat actor creating a malicious file from previously exploited Fortinet vulnerabilities (CVE-2024-21762, CVE-2023-27997, and CVE-2022-42475) within FortiGate prod ...

    @AnnieDo52640257

    15 Apr 2025

    128 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  9. Fortinetのゼロデイ脆弱性、任意のコード実行につながる可能性あり（CVE-2022-42475、CVE-2023-27997、CVE-2024-21762） https://t.co/s2zvEqFPp0 #Security #セキュリティ #ニュース

    @SecureShield_

    15 Apr 2025

    82 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. Compromise and persistent access of Fortinet FortiOS products (CVE-2022-42475, CVE-2023-27997, CVE-2024-21762) https://t.co/RvWSwRITk1 https://t.co/yl2K6pPyT2

    @djhsecurity

    14 Apr 2025

    84 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. Fortinet VPNs Still at Risk Despite Patching Fortinet warns that attackers are maintaining access to compromised FortiGate VPN devices even after security patches. Exploited vulnerabilities include CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762. 🔍 How? Hackers left behind

    @ChbibAnas

    13 Apr 2025

    42 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  12. Fortinet warns that attackers can maintain read-only access to FortiGate devices via a symbolic link, even after patching vulnerabilities like CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762, affecting SSL-VPN-enabled devices. https://t.co/gMCtKRq5gy

    @Cyber_O51NT

    13 Apr 2025

    717 Impressions

    2 Retweets

    4 Likes

    2 Bookmarks

    1 Reply

    0 Quotes

  13. Fortigateデバイスの脆弱性CVE-2022-42475、CVE-2023-27997、CVE-2024-21762などを悪用しユーザーファイルシステムとルートファイルシステムを接続するシンボリックリンクを作成することで読み取り専用アクセスを維持する方法が発見されたとのこと。 https://t.co/n7FwIJDivV

    @ntsuji

    12 Apr 2025

    2640 Impressions

    3 Retweets

    12 Likes

    6 Bookmarks

    2 Replies

    0 Quotes

  14. Fortinetによれば、最近、既知の脆弱性（CVE-2022-42475、CVE-2023-27997、CVE-2024-21762など）を悪用した攻撃が確認され、新しい手法でFortiGate製品に対して”read-only”のアクセスを維持する事例が発見されました。 ただし、SSL-VPNを有効化していない環境は影響を受けません。 https://t.co/rJ9Vc1KSVE

    @t_nihonmatsu

    12 Apr 2025

    416 Impressions

    0 Retweets

    3 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  15. ⚡ Even patching won't save you. Fortinet confirms attackers kept read-only access to FortiGate devices after patching old flaws (CVE-2022-42475, CVE-2023-27997, CVE-2024-21762) via hidden symlink in SSL-VPN. Full details 👉 https://t.co/AbzC2WPo4r

    @TheHackersNews

    11 Apr 2025

    72569 Impressions

    74 Retweets

    154 Likes

    47 Bookmarks

    4 Replies

    8 Quotes

  16. CISAから2023年に良く悪用された脆弱性のまとめが公開されていましたね。 2023 Top Routinely Exploited Vulnerabilities https://t.co/ulfm6a7TUz ◆CVE-2023-3519：Citrix ◆CVE-2023-4966：Citrix ◆CVE-2023-20198：Cisco ◆CVE-2023-20273：Cisco ◆CVE-2023-27997：Fortinet… https://t.co/5hY9DKZUl3 https://t.co/G9ylY3EdvP

    @taku888infinity

    13 Nov 2024

    1354 Impressions

    1 Retweet

    8 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  17. 【独自】F5 BIG-IPにおけるリモートコード実行脆弱性CVE-2023-46747と、FortiOS及びFortiProxyにおけるバッファオーバーフローCVE-2023-27997が、ランサムウェアにより悪用された。米国サイバーセキュリティ・社会基盤安全保障庁(CISA)の既知の悪用された脆弱性カタログが更新。 https://t.co/fyN6WPZRqY

    @__kokumoto

    24 Oct 2024

    1795 Impressions

    4 Retweets

    26 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. 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
  2. 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
  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.