THREATIST.IORead the docs 58 records in Brocade Sannav · all components
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout.
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has ac…
RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix colli…
Brocade SANnav OVA before v2.3.1 and v2.3.0a contain hard-coded credentials in the documentation that appear as the appliance's root password.
Docker daemon in Brocade SANnav before SANnav 2.3.1b runs without auditing.
Brocade SANnav Web interface before Brocade SANnav v2.3.0 and v2.2.2a allows remote unauthenticated users to bypass web authentication and authorization.
In Brocade SANnav, before Brocade SANnav v2.3.0, syslog traffic received clear text.
Brocade SANnav versions before v2.1.0, contain a Plaintext Password Storage vulnerability.
A vulnerability affects Brocade SANnav before v2.3.1 and v2.3.0a.
A vulnerability in Brocade SANnav exposes Kafka in the wan interface.
A vulnerability in Brocade SANnav versions before v2.1.0 could allow a remote authenticated attacker to conduct an LDAP injection.
Brocade SANnav OVA before SANnav 2.3.1b enables SHA1 deprecated setting for SSH for port 22.
A vulnerability, in Brocade SANnav versions before v2.0, could allow remote attackers to brute-force a valid session ID.
When a Brocade SANnav installation is upgraded from Brocade SANnav v2.2.2 to Brocade SANnav 2.3.0, TLS/SSL weak message authentication code ciphers are added by default for port 18082.
When Brocade SANnav before v2.3.1 and v2.3.0a servers are configured in Disaster Recovery mode, the encryption key is stored in the DR log files.
The class FileTransfer implemented in Brocade SANnav before v2.3.1, v2.3.0a, uses the ssh-rsa signature scheme, which has a SHA-1 hash.
Under certain error conditions at time of SANnav installation or upgrade, the encryption key can be written into and obtained from a Brocade SANnav supportsave.
A vulnerability in Brocade SANnav before v2.3.1 and v2.3.0a prints Brocade Fabric OS switch encrypted passwords in the Brocade SANnav Standby node's support save.
Brocade SANnav before SANnav 2.3.1b enables weak TLS ciphers on ports 443 and 18082.
A vulnerability in Brocade SANnav before 2.4.0b and 3.0.0 prints encoded passwords and authentication tokens in log files.
In Brocade SANnav server before v2.3.1 and v2.3.0a, the SSH keys inside the OVA image are identical in the VM every time SANnav is installed.
By default, SANnav OVA is shipped with root user login enabled.
Brocade SANnav before v.2.1.0a could allow remote attackers cause a denial-of-service condition due to a lack of proper validation, of the length of user-supplied data as name for custom field name.
An information disclosure vulnerability exists in Brocade SANnav before v2.3.1 and v2.3.0a when Brocade SANnav instances are configured in disaster recovery mode.
A vulnerability, in The ReportsTrustManager class of Brocade SANnav versions before v2.0, could allow an attacker to perform a man-in-the-middle attack against Secure Sockets Layer(SSL)connections.