CVE-2025-6391 is a Critical severity (CVSS 9.1) flaw in Broadcom Brocade Active Support Connectivity Gateway (ASCG) before 3.3.0, which writes JSON Web Tokens to log files in clear text. Anyone who can read those logs can reuse the tokens. Upgrade to 3.3.0 or later and restrict log access.
The weakness is CWE-532, insertion of sensitive information into a log file. The Gold page for the CVE is CVE-2025-6391 on Gold.
What's affected
- Broadcom Brocade Active Support Connectivity Gateway (ASCG), all versions before 3.3.0
- Fixed version: 3.3.0, according to the CVE description's wording of the affected range
The record references a Broadcom security advisory (number 35951). The Broadcom support portal blocked our automated fetch, so we could not read its fix details or workarounds. Please open the advisory in a browser and confirm the fixed version and any extra steps before you act. This is the one point we have not been able to verify against the vendor page.
The description names three consequences of exposed tokens: unauthorized access, session hijacking and information disclosure. The CVSS vector shows network access, low complexity, no privileges and no user interaction, with high confidentiality and integrity impact.
How to check if you're exposed
Find your ASCG version in the appliance or admin interface. If it is below 3.3.0, it is in scope. Then ask a practical question: who can read the gateway's log files? That includes administrators, backup operators, log shipping agents and any central logging platform that receives copies.
If you collect logs centrally, search them for token shaped strings. A JWT is three base64 text segments separated by dots and usually starts with the characters eyJ. A simple search on a copy of the logs looks like this:
grep -rE "eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+" /path/to/copied/logs | head
If matches appear, tokens have been stored in those logs. Do not paste matches into tickets or chat.
What to do now
- Upgrade ASCG to 3.3.0 or later after reading the Broadcom advisory.
- Restrict read access to the gateway logs and to every system that stores copies, including backups.
- Purge or rotate old log files that may contain tokens, following your retention policy.
- Ask whether tokens issued before the upgrade can be revoked or expired, and do that if the product allows it. Check the advisory for the supported method.
- Review access logs on connected systems for sessions you do not recognise.
- Use the free in-browser dependency scan and the Gold directory to keep a view of the rest of your software.
Try it yourself
Click through it at your own pace, or open it full screen.
Why it matters
A token is a stand in for a password. If it lands in a log, whoever reads the log can borrow the session until the token expires. Logs travel further than most people expect, into backups, support bundles and search platforms, and they are often readable by more staff than the application itself.
The class of weakness is simple and common: code that logs a whole request or header for debugging and nobody removes it. The fix on the vendor side is to stop logging the secret. On your side the lasting lesson is to treat logs as sensitive data. The record does not mark this CVE as known exploited.
Quick check
Does an attacker need to break in to exploit this?
They need access to the log files. The description says an attacker with access to the log files can take the tokens. How easy that is depends on your log permissions.
Which version fixes it?
The description says versions before 3.3.0 are affected. Confirm the fixed version on the Broadcom advisory.
Sources
- NVD record
- Broadcom security advisory 35951 (listed in the record; our fetch was blocked, so confirm details there)
Last reviewed: 18 October 2026.
