Where
AND
AND
-Infinity
0
Severity
6.5
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

A Default Configuration vulnerability in FortiOS may allow an unauthenticated attacker on the same subnet to intercept sensitive information by impersonating the LDAP server.

1 / 2
First published (updated )
Severity
4.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

A Improper Access Control in Fortinet FortiOS 6.0.2, 5.6.7 and before, FortiADC 6.1.0, 6.0.0 to 6.0.1, 5.4.0 to 5.4.4 allows attacker to obtain the LDAP server login credentials configured in FortiGate via pointing a LDAP server connectivity test request to a rogue LDAP server instead of the configured one.

1 / 3
First published (updated )
Severity
4.8
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N/E:P/RL:X/RC:R

An Insufficient Session Expiration vulnerability [CWE-613] in FortiOS SSL-VPN may allow an attacker in possession of a cookie used to log in the SSL-VPN portal to log in again, although the session has expired or was logged out.

1 / 2
Source: FortiGuard
First published (updated )
Severity
6.5
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Fortinet FortiOS contains a use of hard-coded credentials vulnerability that could allow an attacker to cipher sensitive data in FortiOS configuration backup file via knowledge of the hard-coded key.

1 / 2
Source: CISA
First published (updated )
Severity
5.9
Infoleak
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N/E:P/RL:O/RC:C

An Exposure of Sensitive Information to an Unauthorized Actor vulnerability [CWE-200] in FortiOS SSL-VPN may allow a remote unauthenticated attacker to bypass the patch developed for the symbolic link persistency mechanism observed in some post-exploit cases, via crafted HTTP requests. An attacker would need first to have compromised the product via another vulnerability, at filesystem level.

1 / 3
Source: FortiGuard
First published (updated )
Severity
6.5
Buffer Overflow
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

A heap buffer overflow in Fortinet FortiOS 6.0.0 through 6.0.4, 5.6.0 through 5.6.10, 5.4.0 through 5.4.12, 5.2.14 and earlier and FortiProxy 2.0.0, 1.2.8 and earlier in the SSL VPN web portal may cause the SSL VPN web service termination for logged in users due to a failure to properly handle javascript href data when proxying webpages.

1 / 2
First published (updated )
Severity
5.3
Infoleak
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C

A fundamental design flaw within the RADIUS protocol has been proven to be exploitable, compromising the integrity in the RADIUS Access-Request process. The attack allows a malicious user to modify packets in a way that would be indistinguishable to a RADIUS client or server. To be successful, the attacker must have the ability to inject themselves between the client and server.

1 / 6
Source: FortiGuard

Remedy

Disable the use of RADIUS/UDP and RADIUS/TCP - instead RADIUS/TLS or RADIUS/DTLS should be used.

Remedy

TBD

Remedy

The best way to address this issue is by using encrypted and authenticated channels that offer modern cryptographic security guarantees. Configure an alternate authentication mechanism if you are using RADIUS with a CHAP or PAP authentication protocol. PAN-OS provides the following alternate RADIUS authentication mechanisms: PEAP-MSCHAPv2 (default), PEAP with GTC, and EAP-TTLS with PAP. For more information, please see https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/authentication/configure-radius-authentication. In addition, instead of using RADIUS, you can configure an alternate authentication mechanism using one of the options described here: https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/authentication. If you are a Prisma Access customer using a RADIUS configuration with PAP or CHAP in your profile and have not applied one of the changes described above, please reach out to TAC/CS to schedule an upgrade window. PAN-OS 9.1.19, PAN-OS 10.1.14, PAN-OS 10.2.10, PAN-OS 11.0.7, PAN-OS 11.1.3, and all later PAN-OS versions add a new feature to enforce an authentication check in RADIUS. This new feature is disabled by default to match the existing behavior. To enable this feature, run the following commands: > set auth radius-require-msg-authentic yes To confirm that the setting was correctly enabled, run the following command: > show auth radius-require-msg-authentic If set correctly, the response will say "yes". This setting is persistent across reboots. No ‘commit’ is required for this to take effect. Please note that this feature requires that the RADIUS server has been updated to support the new protocol changes, as detailed in https://kb.cert.org/vuls/id/456537. If your RADIUS authentication breaks when radius-require-msg-authentic is set to yes, please work with your RADIUS server vendor for support with the RADIUS server upgrade process.
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203