Insecure Docker mount points in Brocade SANnav expose sensitive files

In Brocade SANnav before Brocade SANnav v2.31 and v2.3.0a, it was observed that Docker instances inside the appliance have insecure mount points, allowing reading and writing access to sensitive files. The vulnerability could allow a sudo privileged user on the host OS to read and write access to these files.

• Brocade identifies Brocade SANnav before v2.3.1 and v2.3.0a as affected.
• The advisory revision states that both SANnav tarball and SANnav OVA deployments are in scope.
• Brocade states that the security update is provided in v2.3.1, v2.3.0a, and later releases. Confirm the applicable deployment branch before upgrading.

The flaw is in the mount-point configuration of Docker instances inside Brocade SANnav. Insecure mounts make certain sensitive files readable and writable from the Docker environment by a user with sudo privileges on the host OS. This is classified as CWE-276, Incorrect Default Permissions, but the advisory does not disclose the mount paths, file list, container names, or exact configuration responsible for the exposure. The issue is locally reachable on the host OS, requires no user interaction, and does not describe a network request or attacker-controlled payload. The precise scope of exposed files remains unknown.

The issue requires local access to the host OS and an account with sudo privileges; based on the available evidence, it is not a remote unauthenticated attack path. The supplied assessment identifies high required privileges, low complexity, and no user interaction. The supplied record marks public exploit as false and does not provide a known-exploitation status; the Brocade advisory also does not describe an exploit or exploitation campaign. This does not prove that exploitation has never occurred. The specific procedure by which a sudo-capable account accesses the affected mounts is not disclosed.

The direct technical outcome is that a local user with sudo privileges can read and write sensitive files mounted into Docker containers. This creates high confidentiality and integrity impact for files within the exposed mounts, while no availability impact is described. Because the required privilege is already high, the issue primarily expands file access on a host where the attacker has substantial authority rather than providing an initial remote entry path. Organisational consequences could include disclosure of configuration or modification of operational data, limited to the files actually exposed by the mounts. The file list, paths, and exact impact boundary are not public in the available evidence.

A user who already has sudo privileges on the host OS may read sensitive data exposed through the Docker mount points. Depending on the contents of those files, this could disclose configuration, operational information, or authentication material, although the specific file types are not identified. Write access could also allow changes to mounted files and potentially alter SANnav configuration or operation. The available evidence does not describe an initial remote-access path or a service-availability impact.

1. Upgrade Brocade SANnav to v2.3.1 or v2.3.0a, depending on the product branch in use. Brocade states that the fix is also included in later releases.
2. Check both SANnav tarball and SANnav OVA software inventories and active hosts; do not assess only one deployment format.
3. While remediation is pending, review and minimize the set of host OS accounts with sudo privileges to reduce the number of users meeting the stated prerequisite.
4. After upgrading, verify the installed version and review the Docker mount configuration to confirm that an affected release is no longer deployed.
5. Brocade does not document a separate workaround. Do not treat manual file-permission changes or mount edits as a confirmed fix unless supported by vendor guidance for the deployment.

1. Inventory Brocade SANnav deployments, including SANnav tarball and SANnav OVA installations, and identify the running product version.
2. Identify the Docker instances inside SANnav and review their mount configuration for mounts that provide read or write access to sensitive host files.
3. Review local accounts with sudo privileges on the host OS, because this is the prerequisite described by the advisory.
4. Review unusual read and write activity involving files exposed to Docker containers through mounts. This is precautionary monitoring, not a vendor-published indicator.
5. Do not treat the absence of suspicious log activity as proof of safety, especially because the affected paths and detailed indicators are not disclosed.