Veille CVE

Recherche « Golang crypto »

19 CVE

Critique 7 Élevée 6 Moyenne 6 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « Golang crypto » ✕
  1. CVE-2026-78662 7.5 Élevée

    golang.org/x/crypto/ssh · Golang crypto

    Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every packet other than the open confirmation/failure, without blocking and without tearing down the connection.

  2. CVE-2026-56855 7.5 Élevée

    golang.org/x/crypto/ssh · Golang crypto

    Previously, after a channel has been established, a malicious peer could send crafted messages that would deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of buffering and blocking.

  3. CVE-2026-56854 7.5 Élevée

    golang.org/x/crypto/ssh

    The source-address critical option in the Permissions returned by an authentication callback was only enforced for the PublicKeyCallback and VerifiedPublicKeyCallback paths, extending the fix for CVE-2026-46595. Permissions returned by the PasswordCallback, KeyboardInteractiveCallback, NoClientAuthCallback, and GSSAPIWithMICConfig.AllowLogin callbacks were not validated against the client's remote address, so a source-address restriction set by those callbacks was silently ignored. The check is now applied to the Permissions returned by any authentication callback.

  4. CVE-2026-42505 5.3 Moyenne

    Go standard library crypto/tls · Golang go

    Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.

  5. CVE-2026-52814 5.5 Moyenne

    gogs

    Gogs is an open source self-hosted Git service. Prior to 0.14.3, the Gogs built-in Go SSH server is vulnerable to an unauthenticated, asymmetric Denial of Service (DoS) attack. The application accepts inbound TCP connections and passes them to golang.org/x/crypto/ssh.NewServerConn inside a new goroutine without enforcing any read/write deadlines on the underlying net.Conn. An unauthenticated attacker can open multiple TCP connections to the SSH port and simply withhold the SSH protocol banner. This forces the server to spawn an unbounded number of goroutines that block indefinitely waiting for socket I/O. This leads to complete File Descriptor (FD) exhaustion, preventing legitimate users from accessing the Git SSH service, and ultimately destabilizing the entire Gogs process (e.g., causing internal log rotation failures). This vulnerability is fixed in 0.14.3.

  6. CVE-2026-46598 5.3 Moyenne

    golang.org/x/crypto/ssh/agent · Golang crypto

    For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used.

  7. CVE-2026-46597 7.5 Élevée

    golang.org/x/crypto/ssh · Golang crypto

    An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs.

  8. CVE-2026-46595 10.0 Critique

    golang.org/x/crypto/ssh · Red Hat Cryostat 4 on RHEL 9 · Red Hat RHEM 1.0 for RHEL 9 · Red Hat RHEM 1.1 for RHEL 10

    Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.

  9. CVE-2026-42508 9.1 Critique

    golang.org/x/crypto/ssh/knownhosts · Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 8 · Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support

    Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @revoked.

  10. CVE-2026-39835 5.3 Moyenne

    golang.org/x/crypto/ssh · Red Hat Cryostat 4 on RHEL 9 · Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 8

    SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.

  11. CVE-2026-39834 9.1 Critique

    golang.org/x/crypto/ssh · Golang crypto

    When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation.

  12. CVE-2026-39833 9.1 Critique

    golang.org/x/crypto/ssh/agent · Golang crypto

    The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested.

  13. CVE-2026-39832 9.1 Critique

    golang.org/x/crypto/ssh/agent · Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 8 · Red Hat Enterprise Linux 8.8 Telecommunications Update Service

    When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them.

  14. CVE-2026-39831 9.1 Critique

    golang.org/x/crypto/ssh · Golang crypto

    The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback.

  15. CVE-2026-39830 9.1 Critique

    golang.org/x/crypto/ssh · Red Hat Cryostat 4 on RHEL 9 · Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 8

    A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.

  16. CVE-2026-39829 7.5 Élevée

    golang.org/x/crypto/ssh · Red Hat Cryostat 4 on RHEL 9 · Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 8

    The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.

  17. CVE-2026-39828 6.3 Moyenne

    golang.org/x/crypto/ssh · Red Hat Cryostat 4 on RHEL 9 · Red Hat RHEM 1.0 for RHEL 9 · Red Hat RHEM 1.1 for RHEL 10

    When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error.

  18. CVE-2026-39827 6.5 Moyenne

    golang.org/x/crypto/ssh · Golang crypto

    An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection.

  19. CVE-2026-42501 7.5 Élevée

    Go toolchain cmd/go · Golang go

    A malicious module proxy can exploit a flaw in the go command's validation of module checksums to bypass checksum database validation. This vulnerability affects any user using an untrusted module proxy (GOMODPROXY) or checksum database (GOSUMDB). A malicious module proxy can serve altered versions of the Go toolchain. When selecting a different version of the Go toolchain than the currently installed toolchain (due to the GOTOOLCHAIN environment variable, or a go.work or go.mod with a toolchain line), the go command will download and execute a toolchain provided by the module proxy. A malicious module proxy can bypass checksum database validation for this downloaded toolchain. Since this vulnerability affects the security of toolchain downloads, setting GOTOOLCHAIN to a fixed version is not sufficient. You must upgrade your base Go toolchain. The go tool always validates the hash of a toolchain before executing it, so fixed versions will refuse to execute any cached, altered versions of the toolchain. The go tool trusts go.sum files to contain accurate hashes of the current module's dependencies. A malicious proxy exploiting this vulnerability to serve an altered module will have caused an incorrect hash to be recorded in the go.sum. Users who have configured a non-trusted GOPROXY can determine if they have been affected by running "rm go.sum ; go mod tidy ; go mod verify", which will revalidate all dependencies of the current module. The specific flaw in more detail: The go command consults the checksum database to validate downloaded modules, when a module is not listed in the go.sum file. It verifies that the module hash reported by the checksum database matches the hash of the downloaded module. If, however, the checksum database returns a successful response that contains no entry for the module, the go command incorrectly permitted validation to succeed. A module proxy may mirror or proxy the checksum database, in which case the go command will not connect to the checksum database directly. Checksums reported by the checksum database are cryptographically signed, so a malicious proxy cannot alter the reported checksum for a module. However, a proxy which returns an empty checksum response, or a checksum response for an unrelated module, could cause the go command to proceed as if a downloaded module has been validated.