Vulnerabilities

A<br /> segmentation fault can occur in Brocade Fabric OS after Brocade Fabric <br /> OS v9.0 and before Brocade Fabric OS v9.2.0a through the passwdcfg <br /> command. This<br /> could allow an authenticated privileged user local user to crash a <br /> Brocade Fabric OS swith using the cli “passwdcfg --set -expire <br /> -minDiff“.

Brocade<br /> SANnav before v2.3.0 and v2.2.2a stores SNMPv3 Authentication passwords<br /> in plaintext. A privileged user could retrieve these credentials with <br /> knowledge and access to these log files. SNMP <br /> credentials could be seen in SANnav SupportSave if the capture is <br /> performed after an SNMP configuration failure causes an SNMP <br /> communication log dump.<br /> <br /> <br />

Brocade SANnav Web interface before Brocade SANnav v2.3.0 and v2.2.2a<br /> allows remote unauthenticated users to bypass web authentication and <br /> authorization.

Possible<br /> information exposure through log file vulnerability where sensitive <br /> fields are recorded in the configuration log without masking on Brocade <br /> SANnav before v2.3.0 and 2.2.2a. Notes:<br /> To access the logs, the local attacker must have access to an already collected Brocade SANnav "supportsave" <br /> outputs.

The <br /> firmwaredownload command on Brocade Fabric OS v9.2.0 could log the <br /> FTP/SFTP/SCP server password in clear text in the SupportSave file when <br /> performing a downgrade from Fabric OS v9.2.0 to any earlier version of <br /> Fabric OS.

An incorrect comparison vulnerability was identified in GitHub Enterprise Server that allowed commit smuggling by displaying an incorrect diff in a re-opened Pull Request. To exploit this vulnerability, an attacker would need write access to the repository. This vulnerability was reported via the GitHub Bug Bounty Program https://bounty.github.com/ .<br />

A Reflected Cross-site scripting (XSS) vulnerability in the file manager tab in Usermin 2.000 allows remote attackers to inject arbitrary web script or HTML via the replace in results field while replacing the results under the tools drop down.

Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session&amp;#39;s "last access" timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade.<br /> <br /> <br />

An issue in Archive v3.3.7 allows attackers to execute a path traversal via extracting a crafted zip file.

An issue in ZIPFoundation v0.9.16 allows attackers to execute a path traversal via extracting a crafted zip file.

An issue in Archive v3.3.7 allows attackers to spoof zip filenames which can lead to inconsistent filename parsing.

GitPython is a python library used to interact with Git repositories. In order to resolve some git references, GitPython reads files from the `.git` directory, in some places the name of the file being read is provided by the user, GitPython doesn&amp;#39;t check if this file is located outside the `.git` directory. This allows an attacker to make GitPython read any file from the system. This vulnerability is present in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175. That code joins the base directory with a user given string without checking if the final path is located outside the base directory. This vulnerability cannot be used to read the contents of files but could in theory be used to trigger a denial of service for the program. This issue has been addressed in version 3.1.37.