GCVE-1-2026-0015

Vulnerability from gna-1 – Published: 2026-02-09 09:09 – Updated: 2026-02-09 09:14
VLAI?
Title
Threat actors use FortiCloud SSO bypass to collect LDAP connection passwords
Summary
**CERT.at gained access to a toolkit of an unknown threat actor targeting FortiCloud SSO bypass in Fortinet appliances (CVE-2025-59718/CVE-2025-59719). We are releasing under TLP:CLEAR key findings about likely post-exploitation goals of the attacker.** The obtained exploit works only for the original vulnerability and is not effective against patched devices. It is, however, known that the flaw still exists and affects all SSO setups in Fortinet appliances. The exploit behavior is consistent with our previous publication -  https://www.cert.at/en/blog/2026/1/look-at-forticloud-sso-bypass-exploitation https://www.cert.at/en/blog/2026/1/look-at-forticloud-sso-bypass-exploitation) . The exploit is prepared to work against FortiGate instances, and in the toolkit, we have found two scripts for the post-exploitation analysis of the collected configuration dumps. The attacker: * looks for the LDAP/AD configuration settings, * is in the possession of the default FortiGate configuration encryption key. The “regular bind“ mode of LDAP/AD connection with FortiGate requires providing user credentials for the appliance, which FortiGate uses to establish a connection with the LDAP server. They are encrypted in the configuration, but by default, the encryption key is static and the same on all instances. We were able to confirm that the key included in the attacker toolkit works on the fresh FortiGate 7.6.5 VM. **Note:** in our tests, we also confirmed that the normal local user passwords are NOT possible to retrieve back. Our understanding is that only the data that is necessary to become back (LDAP connection password for regular bind, private keys for certificates, etc.) could be decrypted. Preventive recommendations -------------------------- We strongly recommend activating the “private data encryption” feature in FortiGate devices, which replaces the default encryption key. This step is also officially recommended by Fortinet as a hardening measure. The encryption key has to be the same in all instances in an HA cluster. Using a custom encryption key helps “buying time” for credential rotation after a configuration leak. As always, CERT.at strongly recommends keeping management interfaces not accessible from the public internet. In the last blog post, the Fortinet PSIRT recommends setting a local-in policy to restrict access on the administrative interface.
Severity ?
7.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H
CWE
  • CWE-1188 - Insecure Default Initialization of Resource
Assigner
References
Impacted products
Vendor Product Version
fortinet fortios Affected: ≤ 7.6.6
Create a notification for this product.
Credits
Kamil Mankowski
Relationships ?
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "fortios",
          "vendor": "fortinet",
          "versions": [
            {
              "lessThanOrEqual": "7.6.6",
              "status": "affected"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Kamil Mankowski"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e**CERT.at gained access to a toolkit of an unknown threat actor targeting FortiCloud SSO bypass in Fortinet appliances (CVE-2025-59718/CVE-2025-59719). We are releasing under TLP:CLEAR key findings about likely post-exploitation goals of the attacker.**\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003eThe obtained exploit works only for the original vulnerability and is not effective against patched devices. It is, however, known that the flaw still exists and affects all SSO setups in Fortinet appliances. The exploit behavior is consistent with our previous publication -\u0026nbsp;\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://www.cert.at/en/blog/2026/1/look-at-forticloud-sso-bypass-exploitation)\"\u003ehttps://www.cert.at/en/blog/2026/1/look-at-forticloud-sso-bypass-exploitation\u003c/a\u003e.\u003cbr\u003e\u003cbr\u003eThe exploit is prepared to work against FortiGate instances, and in the toolkit, we have found two scripts for the post-exploitation analysis of the collected configuration dumps. The attacker:\u003cbr\u003e\u003cbr\u003e*   looks for the LDAP/AD configuration settings,\u003cbr\u003e*   is in the possession of the default FortiGate configuration encryption key.\u003cbr\u003e\u003cbr\u003eThe \u201cregular bind\u201c mode of LDAP/AD connection with FortiGate requires providing user credentials for the appliance, which FortiGate uses to establish a connection with the LDAP server. They are encrypted in the configuration, but by default, the encryption key is static and the same on all instances. We were able to confirm that the key included in the attacker toolkit works on the fresh FortiGate 7.6.5 VM.\u003cbr\u003e\u003cbr\u003e**Note:** in our tests, we also confirmed that the normal local user passwords are NOT possible to retrieve back. Our understanding is that only the data that is necessary to become back (LDAP connection password for regular bind, private keys for certificates, etc.) could be decrypted.\u003cbr\u003e\u003cbr\u003ePreventive recommendations\u003cbr\u003e--------------------------\u003cbr\u003e\u003cbr\u003eWe strongly recommend activating the \u201cprivate data encryption\u201d feature in FortiGate devices, which replaces the default encryption key. This step is also officially recommended by Fortinet as a hardening measure. The encryption key has to be the same in all instances in an HA cluster. Using a custom encryption key helps \u201cbuying time\u201d for credential rotation after a configuration leak.\u003cbr\u003e\u003cbr\u003eAs always, CERT.at strongly recommends keeping management interfaces not accessible from the public internet. In the last blog post, the Fortinet PSIRT recommends setting a local-in policy to restrict access on the administrative interface.\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "**CERT.at gained access to a toolkit of an unknown threat actor targeting FortiCloud SSO bypass in Fortinet appliances (CVE-2025-59718/CVE-2025-59719). We are releasing under TLP:CLEAR key findings about likely post-exploitation goals of the attacker.**\n\n\n\n\nThe obtained exploit works only for the original vulnerability and is not effective against patched devices. It is, however, known that the flaw still exists and affects all SSO setups in Fortinet appliances. The exploit behavior is consistent with our previous publication -\u00a0 https://www.cert.at/en/blog/2026/1/look-at-forticloud-sso-bypass-exploitation https://www.cert.at/en/blog/2026/1/look-at-forticloud-sso-bypass-exploitation) .\n\nThe exploit is prepared to work against FortiGate instances, and in the toolkit, we have found two scripts for the post-exploitation analysis of the collected configuration dumps. The attacker:\n\n*   looks for the LDAP/AD configuration settings,\n*   is in the possession of the default FortiGate configuration encryption key.\n\nThe \u201cregular bind\u201c mode of LDAP/AD connection with FortiGate requires providing user credentials for the appliance, which FortiGate uses to establish a connection with the LDAP server. They are encrypted in the configuration, but by default, the encryption key is static and the same on all instances. We were able to confirm that the key included in the attacker toolkit works on the fresh FortiGate 7.6.5 VM.\n\n**Note:** in our tests, we also confirmed that the normal local user passwords are NOT possible to retrieve back. Our understanding is that only the data that is necessary to become back (LDAP connection password for regular bind, private keys for certificates, etc.) could be decrypted.\n\nPreventive recommendations\n--------------------------\n\nWe strongly recommend activating the \u201cprivate data encryption\u201d feature in FortiGate devices, which replaces the default encryption key. This step is also officially recommended by Fortinet as a hardening measure. The encryption key has to be the same in all instances in an HA cluster. Using a custom encryption key helps \u201cbuying time\u201d for credential rotation after a configuration leak.\n\nAs always, CERT.at strongly recommends keeping management interfaces not accessible from the public internet. In the last blog post, the Fortinet PSIRT recommends setting a local-in policy to restrict access on the administrative interface."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-70",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-70 Try Common or Default Usernames and Passwords"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "privilegesRequired": "HIGH",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Insecure Default Initialization of Resource",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "orgId": "00000000-0000-4000-9000-000000000000"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-647"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios"
        },
        {
          "tags": [
            "mitigation"
          ],
          "url": "https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/102264/configuring-an-ldap-server"
        },
        {
          "tags": [
            "mitigation"
          ],
          "url": "https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-enable-private-data-encryption-feature-on-a/ta-p/339071"
        },
        {
          "tags": [
            "mitigation"
          ],
          "url": "https://docs.fortinet.com/document/fortigate/7.6.0/best-practices/555436/hardening#SecurePassStorage"
        },
        {
          "tags": [
            "mitigation"
          ],
          "url": "https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/363127/local-in-policy"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Threat actors use FortiCloud SSO bypass to collect LDAP connection passwords",
      "x_gcve": [
        {
          "recordType": "update",
          "relationships": [
            {
              "destId": "CVE-2025-59718",
              "type": "related"
            },
            {
              "destId": "CVE-2025-59719",
              "type": "related"
            },
            {
              "destId": "CVE-2026-25815",
              "type": "overlap"
            }
          ],
          "vulnId": "GCVE-1-2026-0015"
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "00000000-0000-4000-9000-000000000000",
    "cveId": "CVE-2026-25815",
    "datePublished": "2026-02-09T09:09:00.000Z",
    "dateUpdated": "2026-02-09T09:14:59.004089Z",
    "requesterUserId": "00000000-0000-4000-9000-000000000000",
    "serial": 1,
    "state": "PUBLISHED",
    "vulnId": "GCVE-1-2026-0015",
    "vulnerabilitylookup_history": [
      [
        "alexandre.dulaunoy@circl.lu",
        "2026-02-09T09:09:48.357212Z"
      ],
      [
        "alexandre.dulaunoy@circl.lu",
        "2026-02-09T09:10:53.252394Z"
      ],
      [
        "alexandre.dulaunoy@circl.lu",
        "2026-02-09T09:11:41.464605Z"
      ],
      [
        "alexandre.dulaunoy@circl.lu",
        "2026-02-09T09:14:59.004089Z"
      ]
    ]
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.