CVE-2026-59293: SMB minimum protocol dialect defaults to SMB1
Unless the application explicitly raises smbMinVersion, the jCIFS client will negotiate down to SMB1/CIFS, which lacks mandatory signing/encryption and is vulnerable to NTLM relay and content-tampering MITM. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Set the jCIFS client property smbMinVersion in the application so it cannot negotiate down to SMB1/CIFS; do not rely on defaults. (Applies to Spring Integration 6.4.0–6.4.12, 6.5.0–6.5.10, 7.0.0–7.0.5, and 7.1.0 unless smbMinVersion is explicitly raised.)
jCIFS client (used by affected application) smbMinVersion = Raise to a value that enforces SMB signing/encryption (do not allow SMB1 negotiation)
Event History
Frequently Asked Questions
Which deployments are exposed to SMB1 downgrade and relay or tampering risks?
Spring Integration deployments using the jCIFS client are exposed when smbMinVersion has not been explicitly raised. The affected listed versions are 7.1.0, 7.0.0 through 7.0.5, 6.5.0 through 6.5.10, and 6.4.0 through 6.4.12.
What conditions does an attacker need to exploit this issue?
An attacker needs network access sufficient to position themselves for a man-in-the-middle attack during SMB negotiation. Exploitation also requires the application to allow negotiation down to SMB1/CIFS by leaving smbMinVersion unset or insufficiently raised.
Are default settings affected?
Yes. Unless smbMinVersion is explicitly raised, the jCIFS client defaults to negotiating down to SMB1/CIFS.
What mitigation is available if upgrading is not immediately possible?
Explicitly raise smbMinVersion so the client cannot negotiate down to SMB1/CIFS. This prevents use of the dialect identified as lacking mandatory signing and encryption.