[Security] Critical CVE found in dutchcoders/transfer.sh:latest #2

Closed
opened 2026-01-19 18:28:36 +00:00 by michael · 2 comments
Owner

Originally created by @felipewnp on GitHub.

Summary

A security scan of the dutchcoders/transfer.sh Docker image reveals one critical vulnerability in a bundled Go dependency: CVE-2024-45337 in golang.org/x/crypto/ssh.
A logic flaw in how ServerConfig.PublicKeyCallback is used can lead to SSH authorization bypass, allowing clients with unintended or unauthorized public keys to be accepted if the application misuses this callback.

Details

  • Image: dutchcoders/transfer.sh
  • Component: Go application and its dependencies
  • Library: golang.org/x/crypto/ssh
  • Vulnerability: CVE-2024-45337
  • Severity: CRITICAL
  • Status: fixed upstream (the library has a fix; this image still uses the vulnerable version)
  • Installed Version: v0.21.0
  • Fixed Version: v0.31.0
  • Title: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
  • Reference: https://avd.aquasec.com/nvd/cve-2024-45337

Technical description

The vulnerability resides in the SSH server implementation in golang.org/x/crypto/ssh:

  • Applications using ssh.ServerConfig.PublicKeyCallback may incorrectly handle SSH public-key authentication when relying on this callback, due to the API’s semantics and how the library invokes it.
  • In certain misuse patterns, the callback can be invoked in a way that does not correctly enforce the intended authorization policy, potentially accepting clients that should be rejected.
  • The risk is highest where:
    • transfer.sh (or any service in the image) exposes an SSH interface for uploads/downloads or administrative access, and
    • Authorization relies on custom logic hooked into ServerConfig.PublicKeyCallback.

Even if the main transfer.sh service primarily uses HTTPS/HTTP, any embedded or sidecar SSH functionality built with this library version is subject to this issue.

PoC

Below is a practical way to reproduce and confirm the vulnerability’s presence in the image at the dependency level.

1. Reproduce via image scan (Trivy)

Prerequisite: Trivy installed (or use the Trivy Docker image).

Run:

docker run --rm -it aquasec/trivy image \
  --scanners vuln \
  --ignore-unfixed \
  --severity CRITICAL \
  --exit-code 1 \
  dutchcoders/transfer.sh

Expected output (simplified):

  • Library: golang.org/x/crypto
  • Vulnerability: CVE-2024-45337
  • Installed Version: v0.21.0
  • Fixed Version: 0.31.0

This confirms that the image is built against the vulnerable golang.org/x/crypto version.

2. (Optional, for maintainers) Locate vulnerable usage in code

If you maintain or fork transfer.sh:

# Inside the application source tree
grep -R "golang.org/x/crypto/ssh" -n .
grep -R "ServerConfig" -n .
grep -R "PublicKeyCallback" -n .

Look specifically for patterns like:

import "golang.org/x/crypto/ssh"

var config ssh.ServerConfig
config.PublicKeyCallback = func(conn ssh.ConnMetadata, key ssh.PublicKey) (*ssh.Permissions, error) {
    // custom authorization logic here
}

Review:

  • Whether all error paths correctly reject unauthorized keys,
  • Whether any fallback behavior might inadvertently treat unknown/invalid keys as accepted,
  • Whether the logic assumes behavior that changed or was clarified in the fixed version.

Impact

What kind of vulnerability is it?

  • Type: Authorization / authentication logic flaw in the SSH server component.
  • Nature: Potential authorization bypass when ServerConfig.PublicKeyCallback is misused, due to library behavior.
  • CWE (conceptual): Best described as misinterpretation or misuse of security-relevant API input, leading to incorrect access-control decisions.

Who is impacted?

  • Any deployment of dutchcoders/transfer.sh that:
    • Uses this image (or derivatives) built with golang.org/x/crypto v0.21.0, and
    • Exposes SSH access that depends on ServerConfig.PublicKeyCallback for public-key-based authorization (e.g., SSH-based upload, admin, or maintenance endpoints).

Practical risk:

  • Authorization bypass via SSH public-key auth:

    • Under certain application usage patterns, an attacker may authenticate over SSH with a key that should not be authorized, gaining capabilities such as:
      • Reading or writing files transferred via SSH if supported,
      • Accessing admin or maintenance SSH endpoints if present,
      • Escalating from “limited” to “full” access, depending on how SSH is integrated.
  • If transfer.sh is deployed without any SSH-based interface, or if SSH is fronted by another component (e.g., a bastion that does not use Go’s x/crypto/ssh), practical impact may be low—but the underlying library is still vulnerable and should be updated.

Originally created by @felipewnp on GitHub. ### Summary A security scan of the `dutchcoders/transfer.sh` Docker image reveals **one critical vulnerability** in a bundled Go dependency: **CVE-2024-45337** in `golang.org/x/crypto/ssh`. A logic flaw in how `ServerConfig.PublicKeyCallback` is used can lead to **SSH authorization bypass**, allowing clients with **unintended or unauthorized public keys** to be accepted if the application misuses this callback. ### Details - **Image:** `dutchcoders/transfer.sh` - **Component:** Go application and its dependencies - **Library:** `golang.org/x/crypto/ssh` - **Vulnerability:** `CVE-2024-45337` - **Severity:** CRITICAL - **Status:** fixed upstream (the library has a fix; this image still uses the vulnerable version) - **Installed Version:** `v0.21.0` - **Fixed Version:** `v0.31.0` - **Title:** `golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto` - **Reference:** [https://avd.aquasec.com/nvd/cve-2024-45337](https://avd.aquasec.com/nvd/cve-2024-45337) **Technical description** The vulnerability resides in the **SSH server implementation** in `golang.org/x/crypto/ssh`: - Applications using `ssh.ServerConfig.PublicKeyCallback` may **incorrectly handle SSH public-key authentication** when relying on this callback, due to the API’s semantics and how the library invokes it. - In certain misuse patterns, the callback can be invoked in a way that **does not correctly enforce the intended authorization policy**, potentially **accepting clients that should be rejected**. - The risk is highest where: - `transfer.sh` (or any service in the image) exposes an SSH interface for uploads/downloads or administrative access, and - Authorization relies on custom logic hooked into `ServerConfig.PublicKeyCallback`. Even if the main `transfer.sh` service primarily uses HTTPS/HTTP, any **embedded or sidecar SSH functionality** built with this library version is subject to this issue. ### PoC Below is a practical way to **reproduce and confirm** the vulnerability’s presence in the image at the dependency level. #### 1. Reproduce via image scan (Trivy) Prerequisite: Trivy installed (or use the Trivy Docker image). Run: ```bash docker run --rm -it aquasec/trivy image \ --scanners vuln \ --ignore-unfixed \ --severity CRITICAL \ --exit-code 1 \ dutchcoders/transfer.sh ``` Expected output (simplified): - `Library: golang.org/x/crypto` - `Vulnerability: CVE-2024-45337` - `Installed Version: v0.21.0` - `Fixed Version: 0.31.0` This confirms that the image is built against the **vulnerable** `golang.org/x/crypto` version. #### 2. (Optional, for maintainers) Locate vulnerable usage in code If you maintain or fork `transfer.sh`: ```bash # Inside the application source tree grep -R "golang.org/x/crypto/ssh" -n . grep -R "ServerConfig" -n . grep -R "PublicKeyCallback" -n . ``` Look specifically for patterns like: ```go import "golang.org/x/crypto/ssh" var config ssh.ServerConfig config.PublicKeyCallback = func(conn ssh.ConnMetadata, key ssh.PublicKey) (*ssh.Permissions, error) { // custom authorization logic here } ``` Review: - Whether **all error paths** correctly reject unauthorized keys, - Whether **any fallback behavior** might inadvertently treat unknown/invalid keys as accepted, - Whether the logic assumes behavior that changed or was clarified in the fixed version. ### Impact **What kind of vulnerability is it?** - **Type:** Authorization / authentication logic flaw in the SSH server component. - **Nature:** Potential **authorization bypass** when `ServerConfig.PublicKeyCallback` is misused, due to library behavior. - **CWE (conceptual):** Best described as **misinterpretation or misuse of security-relevant API input**, leading to incorrect access-control decisions. **Who is impacted?** - Any deployment of `dutchcoders/transfer.sh` that: - Uses this image (or derivatives) built with `golang.org/x/crypto v0.21.0`, and - Exposes SSH access that depends on `ServerConfig.PublicKeyCallback` for **public-key-based authorization** (e.g., SSH-based upload, admin, or maintenance endpoints). **Practical risk:** - **Authorization bypass via SSH public-key auth:** - Under certain application usage patterns, an attacker may **authenticate over SSH with a key that should not be authorized**, gaining capabilities such as: - Reading or writing files transferred via SSH if supported, - Accessing admin or maintenance SSH endpoints if present, - Escalating from “limited” to “full” access, depending on how SSH is integrated. - If `transfer.sh` is deployed **without any SSH-based interface**, or if SSH is fronted by another component (e.g., a bastion that does not use Go’s `x/crypto/ssh`), practical impact may be low—but the underlying library is still **vulnerable** and should be updated.
Author
Owner

@paolafrancesca commented on GitHub:

thanks, @JustAnotherArchivist :)

@paolafrancesca commented on GitHub: thanks, @JustAnotherArchivist :)
Author
Owner

@JustAnotherArchivist commented on GitHub:

This is LLM-generated noise. transfer.sh does not use SSH.

@JustAnotherArchivist commented on GitHub: This is LLM-generated noise. transfer.sh does not use SSH.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#2