[Bug]: Security Issue: SSL/TLS certificate validation

[pirates000333-commits]

Describe the bug

GitHub Issue DescriptionTitle:

Security Issue:
SSL/TLS certificate validation is hardcoded to disabled in FTP connectionsDescription:A review of the FTP connection implementation shows that SSL/TLS certificate verification is permanently disabled. The code explicitly forces the client to ignore certificate errors, which bypasses transport security and leaves the connection vulnerable to Man-in-the-Middle (MitM) attacks.Affected Code Sections

File Path: /opt/iobroker/node_modules/iobroker.script-restore/build/main.js (around line 259)

Function:
ftpConnect(client) and the secondary client access block.javascriptawait client.access({
host: this.config.ftpHost,
port: this.config.ftpPort || 21,
user: this.config.ftpUser || "anonymous",
password: this.config.ftpPassword,
secure: this.config.ftpSecure || false,
secureOptions: { rejectUnauthorized: false } // <--- Permanently disables verification
});

Issue:
The setting secure

Options:
{ rejectUnauthorized: false } is hardcoded. Even if this.config.ftpSecure is enabled, the adapter will connect to any FTP server without validating its SSL/TLS certificate. There is currently no way for the user to enforce a secure, verified connection.

Expected Behavior:
The adapter should provide a configuration option (e.g., rejectUnauthorized or signedCertificatesOnly) in the admin UI. The rejectUnauthorized property should dynamically reflect this user setting instead of being hardcoded to false.

To Reproduce

see funktions mentioned in the description

Expected behavior

The adapter should provide a configuration option (e.g., rejectUnauthorized or signedCertificatesOnly) in the admin UI. The rejectUnauthorized property should dynamically reflect this user setting instead of being hardcoded to false.

Adapter version

0.1.13

JS-Controller version

7.2.2

Node version

v22.23.2

Operating system

Linux version 7.0.14-6-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-6 (2026-07-20T14:45Z)

Checklist of files to include in report

• Adapter log file (Please share the logs in debug mode if possible)
• Screenshots (if applicable to help explain the problem)

Additional log files and screenshots

No response

Additional context

No response

[ipod86]

Thanks for the report — I looked into this closely before making any changes, and I can't reproduce the described vulnerability against the current code.

What I checked:

• The described code (secureOptions: { rejectUnauthorized: false } inside ftpConnect()/client.access()) does not exist in the current source. The actual code (src/main.ts, handleTestFtp and ftpConnect) only passes:

  await client.access({
      host: this.config.ftpHost,
      port: this.config.ftpPort || 21,
      user: this.config.ftpUser || "anonymous",
      password: this.config.ftpPassword,
      secure: this.config.ftpSecure || false,
  });

  No secureOptions is passed at all.

• I also searched the entire git history (git log --all -S"rejectUnauthorized" and -S"secureOptions") across all commits — zero matches. This code path has never existed in this repository.

• I verified the behavior of the underlying basic-ftp library (v6.2.1, currently used): when secureOptions is not provided, it falls through to Node's TLS defaults via tls.connect(). basic-ftp's own netUtils.js explicitly checks tlsOptions.rejectUnauthorized !== false to decide whether to expect a valid certificate — meaning certificate validation is on by default whenever ftpSecure is enabled, exactly the opposite of what's described here.

So as far as I can tell, this adapter is not affected — certificate verification is already active whenever secure FTP is enabled, and there's no hardcoded bypass anywhere in the code or its history.

Could you double-check which version/file you were looking at, or share the exact source (e.g. a link to the line in this repo, or confirm the exact release you tested)? Happy to dig further if there's a real path I'm missing, but I want to avoid "fixing" something that isn't actually broken.