### Impact Nuxt matches route rules case-insensitively by default (mirroring vue-router's default `sensitive: false` routing). The fix for GHSA-mm7m-92g8-7m47 / CVE-2026-53721 lowercased the *lookup* path before matching route rules, but the route-rule *keys* compiled into the matcher were left verbatim. As a result, any route rule whose key contains an uppercase character (for example `/Admin`, `/Dashboard/**`, or the rules Nuxt derives from PascalCase/camelCase page files such as `pages/Admin.vue`) never matches, because every lookup is folded to lowercase while the key stays mixed-case. vue-router still serves the page case-insensitively, so the page renders with none of its Nuxt route-rule protections applied. The most serious consequence is an authorization bypass: an `appMiddleware` rule used as an auth gate (`routeRules: { '/Admin/dashboard': { appMiddleware: 'auth' } }`) is dropped, and `/Admin/dashboard`, `/admin/dashboard`, and `/ADMIN/dashboard` all render the protected page (and its SSR-fetched data) to an unauthenticated visitor instead of redirecting to login. The same gap drops Nuxt's other app-side route-rule behaviours for mixed-case keys, including the client redirect middleware, the app-side `ssr: false` decision, `prerender`, and payload handling. ### Patches Fixed in `[email protected]` (4.x) and `[email protected]` (3.x). The route-rule matcher now case-folds the compiled keys the same way it folds the lookup path, so key and lookup normalisation are symmetric. Both sides are gated on `router.options.sensitive`: with `sensitive: true` (case-sensitive routing) configured casing is preserved on both sides. Scope note: server-emitted per-route `headers`, server `redirect`, and `proxy` are matched by Nitro's own case-sensitive route-rule matcher, not by Nuxt's app-level matcher. They are unchanged by this advisory. The fix covers the app-level protections Nuxt owns (`appMiddleware`, `appLayout`, the client redirect middleware, the app `ssr` decision, `prerender`, and payload). ### Workarounds If you cannot upgrade immediately, any one of: - Key all `routeRules` (and name your page files) in lowercase, so the keys already match the folded lookup path. - Set `router: { options: { sensitive: true } }` so routing and route-rule matching are both case-sensitive and exact (requests must then use the exact casing). - Enforce the sensitive protections server-side independently of route rules (for example a server middleware that checks auth), which does not rely on case-insensitive route-rule matching.

### Impact An unauthenticated attacker can crash a Nuxt server that renders any island / server component containing a `v-for` over a prop (for example `v-for="n in count"` or a `<slot v-for>`). Because the island URL hash is a non-secret digest of the request, the attacker can compute a valid hash for arbitrary props and send the iterated prop as a large integer. The server then expands the `v-for` to that many nodes during SSR, allocating memory proportional to the attacker's number. Reporter figures: `count=8000000` produced a 142.9 MB response; `count=40000000` (and `items=4000000` on a slot list) produced an out-of-memory crash of the worker from a single ~130-byte request. Both the plain `v-for` path (Vue's `ssrRenderList`) and the slot path (`vforToArray`) are affected. ### Patches Fixed in `[email protected]` and `[email protected]`. Island/server-component `v-for` sources are now clamped to a maximum iteration count (`MAX_VFOR_LENGTH = 100000`) at the render boundary, covering the plain path, the `<slot v-for>` element, and the `vforToArray` slot-props helper. Combined with the body-size cap (GHSA-9pgf-384g-p7mv), a single island render can no longer allocate without bound regardless of which `v-for` path is used or whether the prop arrives as an integer or an array. ### Workarounds Avoid `v-for` directly over an unclamped prop in server components, or clamp the count in the component (`v-for="n in Math.min(count, 1000)"`). A body-size limit in front of `/__nuxt_island/` only mitigates array-shaped inputs, not the integer-amplification case. ### References - Bound helper: `packages/nuxt/src/app/components/vfor.ts` - Transform: `packages/nuxt/src/components/plugins/islands-transform.ts` - Slot helper: `packages/nuxt/src/app/components/utils.ts` (`vforToArray`)

## Summary The local backend relies on its configurable filename encoder to prevent remote filename data from becoming operating-system path syntax. If a local destination uses an encoding that omits `Dot`, such as `Slash`, `None`, or `Raw`, a remote object's standard-encoded `．．` component is decoded into an actual `..` component. `backend/local.localPath` then passes the decoded name to `filepath.Join`, which resolves the component and produces a path outside the configured local root. An attacker who can create object names in a remote source that a victim copies or synchronizes to such a local destination can create or overwrite files outside the selected destination directory, with the permissions of the rclone process. The default local encoding includes `Dot` and is not affected by that exact path. This finding requires a non-default local encoding that preserves filesystem path syntax. On Windows, a second confirmed form uses a preserved backslash to turn a remote filename into a native `..\file` path even when the destination encoding still includes `Dot`. This is not merely an odd filename-conversion result. The local remote's configured root is the destination selected by the user, and ordinary backend operations are expected to remain within it. Rclone documents custom and `Raw` encodings as filename-conversion controls; it does not document them as an opt-out from destination confinement. The defect is that confinement depends on an encoding mask instead of an independent post-conversion path check. ## Affected Assets & Attack Surface ### Confirmed affected versions - `v1.51.0` through `v1.74.4` - Local development commit tested: `a0c09f1381ae93e2a9a33c529d170186c61ad058` - Public `master` inspected through commit `c99b2d11edb0986cd2b1190e9fa25a58a3f12661` (2026-07-23) `v1.51.0` introduced the configurable encoding option for the local backend. Encodings such as `None` or `Slash` could omit `Dot` from that version onward. The explicit `Raw` encoding was introduced later, in `v1.68.0`. ### Required destination configuration The destination is a local backend whose effective encoding does not safely encode `.` and `..` components. Examples include: ```text --local-encoding Slash --local-encoding None --local-encoding Raw ``` The first PoC below uses `Slash`. Default configurations are not affected because the platform-specific `encoder.OS` masks include `Dot`. On Windows, custom encodings that omit `BackSlash` can introduce an additional traversal form: an object-key component such as `..\marker.txt` can become a native path separator plus `..`, even if the encoding still contains `Dot`. The fix therefore should enforce containment after conversion to the native path format rather than only require the `Dot` flag. ### Attacker-controlled input The relevant input is an object name returned by a source backend. The confirmed source case is S3: - `backend/s3/s3.go:2554` converts raw object keys to rclone's standard path representation with `f.opt.Enc.ToStandardPath`. - A raw `..` component becomes the standard component `．．`. - When the destination local encoder omits `Dot`, `FromStandardPath` decodes `．．` back to `..`. Amazon S3 permits relative path components when their left-to-right cumulative count does not exceed the preceding non-relative components. Consequently, an object named: ```text tenant/../marker.txt ``` is valid. When the victim's source remote is rooted at `bucket/tenant/`, the relative object name becomes `../marker.txt` before standard encoding. A malicious S3-compatible endpoint can return equivalent keys without relying on Amazon S3. ### Reachable operations The unsafe path resolver is used throughout the local backend, including: - `backend/local/local.go:798` — `localPath` - `backend/local/local.go:803` — `Put` - `backend/local/local.go:979` — `Move` - `backend/local/local.go:1534` — `Object.Update` - `backend/local/local.go:1747` — `Object.Remove` - Local directory creation and object lookup operations that call `localPath` Normal copy and synchronization propagate the source name to the destination: - `fs/sync/sync.go:518` passes `src.Remote()` to `operations.Copy`. - `fs/operations/copy.go:390` uses that remote name for destination `Put` or `Update`. Commands that copy attacker-controlled source objects to a local destination are therefore in scope, including `copy`, `sync`, and `move`. ## Technical Root Cause Analysis Rclone represents backend filenames using its standard encoding. `lib/encoder/standard.go` defines `encoder.Standard` with `EncodeDot`, causing raw names equal to `.` or `..` to be represented by fullwidth characters: ```text . -> ． .. -> ．． ``` When a standard path is converted for a destination backend, `lib/encoder/encoder.go:1214-1240` performs the following transformation for every path component: ```go func FromStandardName(e Encoder, s string) string { if e == Standard { return s } return e.Encode(Standard.Decode(s)) } ``` For a destination encoding that omits `Dot`: 1. `Standard.Decode("．．")` returns `".."`. 2. The destination encoder leaves `".."` unchanged. 3. `FromStandardPath` returns a path containing an actual parent-directory component. The local backend then constructs the native path without validating containment: ```go func (f *Fs) localPath(name string) string { return filepath.Join(f.root, filepath.FromSlash(f.opt.Enc.FromStandardPath(name))) } ``` `filepath.Join` cleans the resulting path. For example: ```text root: /tmp/destination name: ../marker.txt result: /tmp/marker.txt ``` `Put` creates an object from `src.Remote()`, and `Object.Update` eventually opens that resolved path using: ```go os.O_WRONLY | os.O_CREATE | os.O_TRUNC ``` There is no subsequent `filepath.Rel` check, anchored filesystem operation, or rejection of an absolute, volume-qualified, `.` or `..` result. The default encoder masks the defect because it re-encodes `..` as a literal fullwidth directory name. That is not a sufficient security boundary: the encoding is explicitly configurable, including an officially documented `Raw` value that disables conversion. The local backend contains an existing `os.Root` mechanism used while translating symlinks, but ordinary local writes do not use it. In the default non-`--links` mode, `mkdirAll`, `openFile`, rename, and remove operations use ordinary filesystem paths. ## Proof of Concept & Evidence ### Deterministic regression test Add the following test to the `backend/local` package. It requires no external storage service. It uses S3's actual default encoding mask to construct the same standard `Remote()` value that an S3 key with a relative `..` component produces. ```go package local import ( "bytes" "context" "os" "path/filepath" "strings" "testing" "time" "github.com/rclone/rclone/fs/config/configmap" "github.com/rclone/rclone/fs/object" "github.com/rclone/rclone/lib/encoder" "github.com/stretchr/testify/require" ) func TestLocalEncodingWithoutDotEscapesRoot(t *testing.T) { ctx := context.Background() outer := t.TempDir() // S3's default encoder converts a raw ".." object-key component // into rclone's standard fullwidth representation. s3Encoding := encoder.EncodeInvalidUtf8 | encoder.EncodeSlash | encoder.EncodeDot remote := s3Encoding.ToStandardPath("../marker.txt") require.NotEqual(t, "../marker.txt", remote) // The default local encoding includes Dot and keeps the path confined. safeRaw, err := NewFs(ctx, "safe", filepath.Join(outer, "safe"), configmap.Simple{"encoding": encoder.OS.String()}) require.NoError(t, err) safe := safeRaw.(*Fs) rel, err := filepath.Rel(safe.root, safe.localPath(remote)) require.NoError(t, err) require.False(t, rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator))) // Removing Dot converts the same component to a real "..". unsafeRaw, err := NewFs(ctx, "unsafe", filepath.Join(outer, "destination"), configmap.Simple{"encoding": "Slash"}) require.NoError(t, err) unsafe := unsafeRaw.(*Fs) // Place an existing file outside the configured destination. escaped := filepath.Join(filepath.Dir(unsafe.root), "marker.txt") require.NoError(t, os.WriteFile(escaped, []byte("original"), 0600)) payload := "attacker-controlled" src := object.NewStaticObjectInfo( remote, time.Now(), int64(len(payload)), true, nil, nil) _, err = unsafe.Put(ctx, bytes.NewBufferString(payload), src) require.NoError(t, err) got, err := os.ReadFile(escaped) require.NoError(t, err) require.Equal(t, payload, string(got)) } ``` Run: ```text go test ./backend/local -run '^TestLocalEncodingWithoutDotEscapesRoot$' -count=1 -v ``` Observed result against commit `a0c09f1381ae93e2a9a33c529d170186c61ad058`: ```text === RUN TestLocalEncodingWithoutDotEscapesRoot --- PASS: TestLocalEncodingWithoutDotEscapesRoot PASS ``` The test establishes both sides of the issue: - The default local encoding keeps the generated path under the root. - `encoding=Slash` causes `Put` to overwrite a pre-existing file outside the root. ### Confirmed Windows backslash variant A second regression test was run on Windows using the standard remote name: ```text ..\backslash-marker.txt ``` and a local destination configured with: ```text encoding = Slash,Dot ``` This mask retains `Dot`, so it is not vulnerable to the fullwidth-dot decoding sequence above, but it omits `BackSlash`. `FromStandardPath` consequently preserves the backslash; after native conversion, `filepath.Join` interprets it as a separator and resolves the preceding `..`. Calling `Put` overwrote a marker next to the destination root. The test passed on Windows/amd64 against commit `a0c09f138`. This variant demonstrates why rejecting only configurations that omit `Dot` is incomplete. The security check must run after conversion to the platform's native path representation. ### S3 command-line reproduction Perform this test only with a disposable bucket and temporary local paths. ```bash printf 'attacker-controlled\n' > payload.txt aws s3api put-object \ --bucket "$BUCKET" \ --key 'tenant/../rclone-traversal-marker.txt' \ --body payload.txt rm -rf /tmp/rclone-destination rm -f /tmp/rclone-traversal-marker.txt mkdir -p /tmp/rclone-destination rclone copy \ "s3remote:${BUCKET}/tenant/" \ /tmp/rclone-destination \ --local-encoding Slash \ -vv test ! -e /tmp/rclone-destination/rclone-traversal-marker.txt test -f /tmp/rclone-traversal-marker.txt grep -F 'attacker-controlled' /tmp/rclone-traversal-marker.txt ``` Expected result: ```text /tmp/rclone-traversal-marker.txt ``` is created outside: ```text /tmp/rclone-destination ``` The S3 key is rooted under the string prefix `tenant/`, so it is returned by a listing of that prefix. Rclone preserves its logical `..` component using standard encoding until the custom local destination encoder decodes it. ## Impact Assessment The direct impact is creation or overwrite of files outside the configured local destination as the rclone process user. Realistic consequences include: - Destruction or corruption of files accessible to the rclone account. - Modification of user startup files, application configuration, service data, or executable search paths. - Possible persistence or code execution in the rclone user's security context if the attacker can target a file that another component subsequently executes or loads. - Greater host impact when rclone runs as a privileged backup, synchronization, container, or system service account. Default local configurations are protected from the demonstrated `..` component by `Dot` encoding. The required non-default encoding materially reduces exploitability but does not make the behavior safe or expected: disabling filename conversion should cause unrepresentable names to fail, not reinterpret an object name as a path outside the selected destination. ## Remediation Guidance ### Enforce containment after native-path conversion The primary fix should be in the local backend, after `FromStandardPath` and `filepath.FromSlash` have produced the native path. Security must not depend on any particular encoding mask. Refactor `localPath`, or introduce a checked equivalent, so it can return an error. The check should: 1. Convert the standard remote name using the configured local encoding. 2. Convert separators to the native format. 3. Reject any non-empty result for which `filepath.IsLocal` is false. This rejects absolute, volume-qualified, and lexically escaping paths using platform-aware rules. 4. Join the result to `f.root`. 5. Calculate `filepath.Rel(f.root, candidate)` using the normalized `f.root`, not the original user-supplied root string. 6. Reject `rel == ".."`, any relative path beginning with `".." + filepath.Separator`, and any absolute relative result. Illustrative logic: ```go func (f *Fs) checkedLocalPath(remote string) (string, error) { native := filepath.FromSlash(f.opt.Enc.FromStandardPath(remote)) // Some root-level backend operations legitimately resolve the empty name. if native != "" && !filepath.IsLocal(native) { return "", fmt.Errorf("invalid local object path %q: not a local relative path", remote) } candidate := filepath.Join(f.root, native) rel, err := filepath.Rel(f.root, candidate) if err != nil { return "", fmt.Errorf("invalid local object path %q: %w", remote, err) } if filepath.IsAbs(rel) || rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator)) { return "", fmt.Errorf("local object path %q escapes the configured root", remote) } return candidate, nil } ``` This is illustrative rather than a complete patch. The implementation should account for the local backend's Windows UNC normalization and return an existing rclone path-validation error type if one is available. A naive string-prefix comparison must not be used because paths such as `/root-other` share a textual prefix with `/root`. `filepath.IsLocal` protects the decoded relative name, while the independent `filepath.Rel` check verifies the final candidate against the normalized root. Retaining both makes the intended invariant explicit. ### Apply the check to every local filesystem entry point The checked resolver must protect all operations that accept an `fs` remote name, not only `Put`. At minimum, review and update: - `NewObject` and object construction. - `Put`, `PutStream`, and `Update`. - `Mkdir`, `Rmdir`, and directory metadata operations. - `Move`, `DirMove`, and copy/rename helpers. - `Remove` and cleanup of failed or partial transfers. - Metadata and hash operations that resolve a remote name to a local path. If changing `localPath` to return an error is impractical, validate the decoded path before constructing an `Object` or `Directory` and ensure no public backend operation can reach the unchecked helper. ### Consider anchored filesystem operations The existing `os.Root` support in `backend/local/local.go` rejects paths that escape its root and may be reusable. Applying anchored operations to all local mutations would provide stronger protection against both lexical traversal and symlink races. This requires compatibility review: ordinary local copies currently may intentionally follow pre-existing destination symlinks when symlink translation is disabled. A lexical containment check can fix this finding without changing that behavior, whereas applying `os.Root` universally may intentionally prevent writes through symlinks that point outside the root.

Rclone is a command-line program to sync files and directories to and from different cloud storage providers. Prior to 1.74.4, rclone archive extract can write extracted files outside the user-selected destination prefix when extracting a crafted archive containing parent path components such as ../, allowing creation or overwrite of sibling objects in the same bucket or path scope. This issue is fixed in version 1.74.4.

Rclone is a command-line program to sync files and directories to and from different cloud storage providers. Prior to 1.74.4, rclone serve restic --private-repos enforces authorization using the routed user path segment while building the backend object key from the raw uncleaned URL path, allowing an authenticated user to include .. in a request such as //..//config and read, overwrite, or delete another user's private repository on backends that clean path components. This issue is fixed in version 1.74.4.

## 1. Summary rclone interpolates remote SFTP paths into PowerShell hash commands. Its quoting helper escapes only ASCII apostrophe, although PowerShell accepts four Unicode smart quotes as single-quote delimiters. An attacker-controlled filename can therefore terminate the intended path literal and append PowerShell statements executed as the victim's SSH account. ## 2. Affected Assets & Attack Surface - Audited commit: `a0c09f1381ae93e2a9a33c529d170186c61ad058` - Backend: `backend/sftp` - Relevant code: - `backend/sftp/sftp.go:1802-1812` — PowerShell hash commands - `backend/sftp/sftp.go:1663-1699` — `Fs.run` - `backend/sftp/sftp.go:1988-2067` — `Object.Hash` - `backend/sftp/sftp.go:2071-2090` — `quoteOrEscapeShellPath` - Exposed input: remote filename controlled by an SFTP collaborator, upstream storage source, or other party able to create or rename files. - Required execution context: PowerShell as the SSH command shell, SSH exec enabled, and server-side hashing invoked. ## 3. Technical Root Cause Analysis For PowerShell, `quoteOrEscapeShellPath` wraps a path in ASCII apostrophes and doubles only `U+0027`: ```go return "'" + strings.ReplaceAll(shellPath, "'", "''") + "'", nil ``` Windows PowerShell also treats `U+2018`, `U+2019`, `U+201A`, and `U+201B` as single-quote delimiters. Those characters pass through the rclone encoder and can close the quoted path. The completed string is sent as shell source through an SSH exec request. The security boundary fails because shell syntax is constructed by string concatenation rather than passing data through a non-code channel. ## 4. Proof-of-Concept & Evidence - Each of the four Unicode smart quotes was passed through the production quoting function and used to terminate the path literal. - A harmless injected `Set-Content` statement created a marker file. - The stronger test invoked the exact production `Object.Hash` path and MD5 PowerShell command against a fake SSH session backed by local PowerShell. - A valid prefix file allowed `Get-FileHash` to complete; the appended statement then executed. - The filename used only characters permitted by Windows filesystems and did not depend on slash, colon, pipe, or ASCII apostrophe. - The focused test passed normally and under Go's race detector. Reproduction outline: 1. Configure an SFTP remote whose command shell is PowerShell. 2. Enable or autodetect the PowerShell hash command. 3. Place a file whose name contains a smart quote followed by a harmless marker-writing statement and PowerShell comment syntax. 4. Trigger an rclone operation that calculates the remote hash. 5. Observe the marker created with the SSH account's permissions. ## 5. Impact Assessment Successful exploitation provides arbitrary command execution as the victim's SSH account. This can permit file theft, modification, deletion, credential access, persistence, and lateral movement allowed by that account. The attacker needs filename-control capability but does not need the victim's SSH credentials or an interactive shell. The rclone user's hash operation supplies the execution step.

The Autoship Cloud for WooCommerce Subscription Products plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'autoship-create-scheduled-order-action' shortcode in all versions up to, and including, 2.8.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

## 1. Summary A valid but nondefault FTP filename encoding can restore raw CR/LF immediately before an attacker-controlled path is interpolated into the line-oriented FTP control channel. The dependency does not reject CR or LF in command arguments, so a filename can inject an independent authenticated command. A real test server observed the injected `DELE` command. The default FTP encoding and the configuration-wizard examples include `Ctl` and are not vulnerable to the demonstrated filename. A manual custom encoding that omits `Ctl`/`CrLf` is mandatory and is reflected as High attack complexity. The credible trust boundary is a lower-trust source namespace feeding a more-privileged FTP destination: if the attacker already has equivalent rights on that destination, the report establishes a bug but no privilege gain. Protocol framing must still be enforced at the command sink because a filename-compatibility encoder is not a safe substitute for command-argument validation. ## 2. Affected Assets & Attack Surface - Verified rclone revision: `a0c09f1381ae93e2a9a33c529d170186c61ad058` (`v1.74.0-240-ga0c09f138`) - Current-master check: the relevant paths remained present at commit `961266888fe797390c535386f3b3aa46f4853602` on 2026-07-18 - rclone FTP encoding: `backend/ftp/ftp.go:232-248`, `768-785` - Encoder masks/conversion: `lib/encoder/encoder.go:36-68`, `121-152`, `1144-1165` - FTP command sinks: `backend/ftp/ftp.go:1071-1173`, `1309-1428` - Dependency: `github.com/jlaffaye/[email protected]` - Dependency command formatting: `ftp.go:604-610`, with path-bearing callers at `ftp.go:893-947`, `1010-1026`, and `1069-1080` - Preconditions: an attacker can create a filename in a source namespace, the victim copies/syncs it to an FTP destination with greater authority, and that destination uses a manually configured encoding that leaves CR/LF raw - Platform note: Unix and some remote backends can supply newline-bearing names; a local Windows source cannot create the demonstrated filename ## 3. Technical Root Cause Analysis Rclone represents control characters safely in its internal Standard encoding. Immediately before an FTP operation, `FromStandardPath` decodes that representation and applies the configured backend mask. If the mask omits `Ctl`/`CrLf`, raw newlines are restored. The dependency then formats the resulting argument onto a CRLF-delimited control stream through `textproto.Conn.Cmd` without validating it. Reversible filename representation is therefore being used as the only protection for a protocol-command boundary. ## 4. Proof-of-Concept & Evidence The source filename was equivalent to: ```text victim\r\nDELE other-secret\r\nNOOP ``` With the default encoding, no raw newline reached the command. With the valid nondefault configuration `encoding = Slash`, `FromStandardPath` restored raw CRLF. During a real FTP path operation, the server parsed `DELE other-secret` as an independent authenticated command. This establishes injection, not merely unsafe serialization. The test did not establish confidentiality impact or operating-system command execution. ## 5. Impact Assessment Injected commands run with the configured FTP account's permissions. Demonstrated direct impact is deletion of a different path, with corresponding integrity and availability loss inside that account. Other FTP filesystem commands may be reachable, but confidentiality and arbitrary operating-system command execution are not claimed. The privilege-boundary case requires the victim's FTP account to have more authority than the attacker has in the source namespace. ## 6. Remediation Guidance - Reject CR and LF in every FTP command argument at the lowest command-construction boundary. - Apply the check to paths, usernames, passwords, rename arguments, and all other formatted fields. - Return an error rather than silently normalizing an unsafe argument. - Keep the default encoder protection as defense in depth and reject an FTP encoding configuration that can restore CR/LF. - Add end-to-end tests for CR, LF, CRLF, and each path command.

The fix for CVE-2026-12044 in pgAdmin 4 9.16 hardened qtLiteral and switched sixteen COMMENT ON / pgstattuple / pgstatindex templates to it, but missed several sinks that had been placed in test_sql_string_literal_lint.py's ALLOWLIST on the incorrect assumption that schema, table, publication, and subscription names sourced from pg_catalog via the browser tree could never contain an apostrophe. PostgreSQL permits arbitrary characters in quoted identifiers, so a low-privileged user able to CREATE TABLE, CREATE PUBLICATION, or CREATE SUBSCRIPTION can plant an apostrophe'd object name that breaks out of the unescaped '{{ name }}' template interpolation the moment any user (including a higher-privileged one) opens that object's Statistics or Dependencies tab, allowing arbitrary SQL statement injection in the viewing user's database session. Affected sinks: the Index Statistics query for all-indexes listing (coll_stats.sql, both the 16_plus and default PostgreSQL-version template variants -- distinct from the single-index stats.sql path already fixed in CVE-2026-12044), and the publication and subscription dependencies.sql / get_position.sql templates (both the pg and ppas/EPAS dialect variants for publications). Fix switches all of these templates to qtLiteral(conn) for name interpolation, and updates publications/__init__.py and subscriptions/__init__.py to pass conn=self.conn into the dependencies.sql render_template call so the qtLiteral filter has a connection to quote against. The corresponding ALLOWLIST entries in test_sql_string_literal_lint.py are removed now that these sinks are properly escaped rather than merely assumed safe. A behavioral regression test renders each fixed template with a stacked-statement apostrophe payload and asserts both that the object name appears exactly as qtLiteral-escaped and that the rendered SQL parses as exactly one statement, verifying the assertion genuinely fails against the pre-patch raw-interpolation form. This issue affects pgAdmin 4: the Index Statistics sink from 1.0, and the Publications/Subscriptions sinks from 5.0, both before 9.17.

IBM WebSphere Application Server 9.0, and 8.5 is affected by a remote code execution vulnerability in the SOAP/JMX connector.

IBM Db2 12.1.0 through 12.1.4 federated server is vulnerable to a denial of service when running non fenced federated queries.

In Eclipse Milo versions 1.0.0 through 1.1.4, the Call service dispatches the original mixed batch to address-space handlers after calculating authorization, allowing an anonymous or otherwise low-privileged client to execute a denied method by batching it with an allowed method.

IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 is vulnerable to buffer overflow in setgid helper db2flacc.

Joomla Extension - joomlacontenteditor.net - Creation of hidden files and unintended file overwrite via rename function in Joomla Content Editor (JCE) < 2.20.2 - Improper input validation in the file rename functionality allowed an authenticated user with file management permissions to rename files to otherwise invalid names, resulting in the creation of hidden files. The issue also allowed existing files at the destination path to be unintentionally replaced.

In Eclipse Milo versions 1.0.0 through 1.1.4, `OpcUaServerConfig.copy()` fails to preserve a configured `RoleMapper`. On servers that rely on role permissions and construct the running configuration through `copy()`, sessions receive no role IDs and the default access controller skips role-permission checks, allowing an anonymous client where anonymous sessions are permitted to read role-permission metadata, invoke protected methods, or delete protected nodes.

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Traffic Server. This issue affects Apache Traffic Server: from 10.0.0 through 10.1.3, from 9.0.0 through 9.2.14. Users are recommended to upgrade to version 9.2.15 or 10.1.4, which fixes the issue.

Regular Expression without Anchors vulnerability in Apache Traffic Server. This issue affects Apache Traffic Server: from 10.0.X through 10.1.3, from 9.0.X through 9.2.14. Users are recommended to upgrade to version 9.2.15 or 10.1.4, which fixes the issue.

In Eclipse Milo versions 0.6.0 through 1.1.4, username-token processing returns distinguishable errors for invalid RSA PKCS#1 v1.5 padding and other authentication failures, allowing an on-path attacker who captures a victim's `Basic128Rsa15`-encrypted username token to use repeated unauthenticated `ActivateSession` requests as a padding oracle, recover the victim's password, and authenticate with the recovered credentials.

In SERVER mode, pgAdmin 4 enforces authentication per route via the @pga_login_required decorator; the application's before_request hook only handles desktop-mode auto-login and the Kerberos/Webserver-auth redirect, so any route shipped without the decorator is reachable without authentication (CWE-306). This is the same defect class previously fixed as CVE-2026-12046 (the sqleditor close/update_connection routes). A follow-up sweep, prompted by a report describing an incomplete fix for CVE-2026-12046, found further routes missing @pga_login_required: the Constraints blueprint's nodes and proplist (object listing) routes and its delete route (a state-mutating DELETE that removes table constraints); preferences.get_all_cli (GET, discloses all CLI-settable preference values); debugger.close (DELETE); and schema_diff.close (DELETE). An unauthenticated network client could therefore enumerate constraint metadata, delete table constraints, read preference values, and force-close debugger or schema-diff sessions belonging to other users, without ever authenticating. Fix adds the missing @pga_login_required decorator (and the corresponding import to the Constraints module) to each of these routes. The change is decorator-only; no behavioral changes to the underlying handlers. This issue affects pgAdmin 4 in SERVER mode: the Constraints and Debugger routes from 1.0, the Schema Diff close route from 4.18, and preferences.get_all_cli from 8.2, all before 9.17.

In Eclipse Milo versions 1.0.0 through 1.1.4, monitored-item quota accounting is not exception-safe: if item creation fails with an unchecked error, the server-global reservation is not restored. Deeply nested PubSub ExtensionObjects in a `CreateMonitoredItems` event filter can trigger a `StackOverflowError` during decoding, allowing an unauthenticated remote client to exhaust a finite global monitored-item quota and prevent all clients from creating new monitored items until restart. Existing monitored items and other server functions remain unaffected.

## 1. Summary The shared HTTP CONNECT helper parses a proxy response with `http.ReadResponse` over an unrestricted buffered reader. The production helper accepted a valid response containing a 2 MiB header in three consecutive runs. A malicious or compromised configured proxy, or an active on-path actor controlling a plaintext HTTP-proxy hop, can grow memory until the process fails. The security impact is process-wide exhaustion, not loss of access through the malicious proxy, which the proxy already controls. The victim must configure and use the proxy, so UI is Required and the rating is Medium. ## 2. Affected Assets & Attack Surface - Verified rclone revision: `a0c09f1381ae93e2a9a33c529d170186c61ad058` (`v1.74.0-240-ga0c09f138`) - Current-master check: `lib/proxy/http.go` was unchanged at master commit `961266888fe797390c535386f3b3aa46f4853602` on 2026-07-18 - Shared helper: `lib/proxy/http.go:23-81` - SFTP use: `backend/sftp/ssh_internal.go:25-45` - FTP use: `backend/ftp/ftp.go:465-479` - Proxy peer: configured malicious/compromised proxy or active on-path actor for a plaintext HTTP proxy - TLS boundary: HTTPS proxy connections authenticate the proxy before this response is parsed, so an on-path actor must also defeat TLS ## 3. Technical Root Cause Analysis `HTTPConnectDial` invokes `http.ReadResponse(br, req)` directly. This call does not inherit `http.Transport.MaxResponseHeaderBytes`. In the Go implementation used for validation, exported `textproto.Reader.ReadMIMEHeader` passes `math.MaxInt64` limits, and `textproto.NewReader` explicitly instructs callers to use `io.LimitReader` or an equivalent bound for denial-of-service resistance. Rclone supplies no bound or total CONNECT-handshake deadline. The helper additionally returns the raw connection, so a safe remediation must preserve any tunnel bytes already buffered after the CONNECT response. ## 4. Proof-of-Concept & Evidence 1. Configure the helper to use a test proxy. 2. Accept rclone's CONNECT request. 3. Return `HTTP/1.1 200 Connection Established` with an `X-Fill` header containing 2 MiB of data. 4. The actual helper parses and accepts the entire response without a fixed ceiling; this succeeded in all three reruns. The test establishes unbounded parsing behavior without intentionally exhausting the host. ## 5. Impact Assessment Large or concurrent CONNECT responses can terminate the rclone process and interrupt unrelated FTP/SFTP remotes and mounts. Runtime OOM cannot be contained by RC panic recovery. SFTP reaches this parser before SSH server authentication, so target host-key validation does not constrain a malicious proxy; HTTPS proxy authentication does constrain ordinary on-path attackers. ## 6. Remediation Guidance - Enforce a total CONNECT status/header budget before parsing. - Add a fixed total handshake deadline as well as idle deadlines. - Close the connection on an oversized or malformed response. - Return a wrapper that consumes already buffered post-response tunnel bytes before the raw connection. - Test large single/multiple headers, slow streaming, and concurrent handshakes.

/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own. Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials. This issue affects pgAdmin 4: from 9.0 before 9.17.

IBM Langflow OSS 1.0.0 through 1.10.3 could allow an authenticated attacker to execute arbitrary code due to a cryptographic weakness in the custom component validation mechanism. When the optional hardening mode that restricts execution to trusted component templates is enabled, the application validates component code using a truncated SHA‑256 hash. Because the hash comparison relies on only a portion of the digest, an attacker can craft malicious component code that collides with a trusted template hash and bypasses validation. Successful exploitation allows the attacker to introduce and execute unauthorized Python code within the Langflow process, defeating the intended security control and potentially leading to full compromise of the affected instance.

IBM Langflow OSS 1.0.0 through 1.10.3 contain an authorization bypass vulnerability in the MemoryComponent that allows authenticated users to access chat history of other users via session_id collision. The MemoryComponent.retrieve_messages and store_message methods filter on session_id without validating flow_id or user_id ownership, enabling cross-user information disclosure through multiple authenticated API endpoints including /api/v1/run/*, /api/v1/responses, and /api/v2/workflow/*. This vulnerability only affects multi-user deployments with LANGFLOW_AUTO_LOGIN=False.

IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote attacker to inject arbitrary code on the system, due to the improper control of user input code.

IBM Langflow OSS 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 use Python's non-cryptographic random module for generating Fernet encryption keys from user secrets under 32 characters. The deterministic Mersenne Twister PRNG produces identical keys for identical seeds, allowing attackers to reproduce encryption keys and decrypt stored API keys and authentication tokens.

IBM Langflow OSS 1.0.0 through 1.10.3 installations allow anyone on the internet to execute arbitrary code on the server without any credentials via 2 HTTP requests.

IBM Langflow OSS 1.0.0 through 1.10.3 does not properly validate the username field, allowing attackers to inject path traversal sequences and bypass containment checks. This enables multiple severe impacts, including arbitrary directory deletion, cross-tenant data destruction, and JWT signing key deletion leading to session invalidation.

A cross-site request forgery vulnerability in the Admin UI of Progress MarkLogic Server before 11.3.6 and 12.0.3 allows a remote attacker who lures an authenticated administrator to a malicious web page to perform administrative actions on the administrator's behalf. This can result in unauthorized changes to security configuration.

Spacebar Server before commit 51da17c contains a missing authorization vulnerability that allows any authenticated user to enumerate complete guild membership by querying the GET /guilds/{guild_id}/roles/{role_id}/member-ids endpoint without guild membership verification. Attackers can exploit the unprotected route handler in the roles member-ids endpoint, which lacks permission checks present in sibling endpoints, to retrieve the full list of member user IDs for any guild on the instance using only a valid bearer token and a known guild ID.

Spacebar Server before commit dcfd910 contains a missing authorization vulnerability that allows any authenticated attacker to add themselves to arbitrary group DM channels by sending a PUT request to the channels recipient endpoint without membership verification. Attackers can exploit the unguarded PUT /channels/{channel_id}/recipients/{user_id} handler to join private group DMs, read complete message history, post messages as a participant, and force-add third-party users without their consent.

boringproxy through 0.10.0 contains a resource exhaustion vulnerability that allows any authenticated user to permanently exhaust server file descriptors, goroutines, and memory by sending requests to the GET /loading endpoint with attacker-supplied id query parameter values. Because the handler performs no map-lookup validity check and receives on a nil channel that blocks forever, with no timeout, no context cancellation, and no server-side reclamation due to absent HTTP server timeouts, each malicious request permanently holds one goroutine, one file descriptor, and approximately 50 kB of memory until the server's file descriptor limit is reached and listener Accept calls fail, halting all tunnel traffic forwarding for all users.

boringproxy through 0.10.0 contains a newline injection vulnerability that allows authenticated low-privileged users with tunnel-creation permission to inject arbitrary lines into the server account's SSH authorized_keys file by supplying a percent-encoded newline character in the domain parameter of the tunnel creation endpoint. Attackers can insert an unrestricted public key entry into authorized_keys to gain persistent shell access, and subsequently read cleartext credentials from the database file including all user tokens, tunnel private keys, and TLS certificates.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3, requests to open external protocol URLs from web content did not take iframe sandbox restrictions into account, so a sandboxed iframe could cause an OS-registered external application to be launched. The frame sandbox state was also not made available to the app permission handlers, affecting apps that render untrusted content in sandboxed iframes and grant the openExternal permission by default when no setPermissionRequestHandler is installed. This issue is fixed in 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1, the mode option of webContents.openDevTools() was not sanitized before use by the DevTools frontend. If an attacker can influence this value, script under their control may run in the DevTools context, which in unsandboxed configurations has access to Node.js, including when untrusted input reaches the mode argument of openDevTools() or untrusted content calls openDevTools() on a webview it embeds. This issue is fixed in 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1.

MaxSite CMS contains a remote code execution vulnerability that allows unauthenticated attackers to inject arbitrary PHP code into the application configuration file by submitting crafted POST requests to the install endpoint after installation is complete. Attackers can supply a malicious db_dbprefix value containing a single quote to break out of a PHP string literal in application/config/database.php, appending attacker-controlled PHP statements that are executed by the web server on every subsequent request, resulting in persistent unauthenticated remote code execution as the web-server process user.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 until 0.11.0, DELETE /api/v1/chats/{id} cancelled a chat's in-flight tasks before checking whether the caller could delete that chat. Any authenticated user who knew another user's chat id could abort that user's running model response, title generation, or tag generation, even though the delete was refused and no chat data was deleted, modified, or disclosed. This issue is fixed in 0.11.0.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the POST /api/v1/oauth2-credential/refresh/:credentialId endpoint is included in WHITELIST_URLS and requires no authentication. The endpoint decrypts the stored credential, sends a refresh request to the configured OAuth provider with the client secret and refresh token, and returns the refreshed access_token in the response body. An attacker with a credential ID can use the token to access the victim's connected service and can also exhaust refresh-token quota. This issue is fixed in 3.1.3.

Jenkins Ivy Report Plugin 1.2 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks when processing Ivy report files.

Missing permission checks in Jenkins AWS CodeBuild Plugin 0.59 and earlier allow attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.

Missing permission checks in Jenkins CodeSonar Plugin 3.6.0 and earlier allow attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.

A missing permission check in Jenkins Violation Comments to GitLab Plugin 2.62.0 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.

Jenkins Horreum Plugin 0.16.162.v33b_4a_a_b_5f828 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to have Jenkins send credentials they are not entitled to use to the administrator-configured Horreum URL.

Jenkins Google Chat Notification Plugin 166.ve6b_de280f2e8 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to use.

Jenkins Summary Display Plugin 1.15 and earlier does not escape the job name in a JavaScript context in build report pages, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Create or Item/Configure permission.

Jenkins Qualys Container Scanning Connector Plugin 1.8.0.5 and earlier does not escape user-controlled field values in a JavaScript context, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

Jenkins XML Job to Job DSL Plugin 0.1.13 and earlier does not perform permission checks, allowing attackers lacking appropriate permissions to invoke the conversion functionality.

SnailJob 1.7.0 contains a denial of service vulnerability in the FuryUtil.deserialize helper that allows authenticated attackers to crash the server by supplying a crafted Zstandard-compressed payload with an inflated frame_content_size field in the frame header. Attackers can store a base64-encoded Zstandard payload declaring an arbitrarily large decompressed size in a retry task argument, causing the JVM to attempt an unbounded array allocation and triggering an unrecoverable java.lang.OutOfMemoryError when the task is dispatched through the retry-task pipeline.

Milvus through 2.6.22 and 3.0.0 contains an unauthenticated denial of service vulnerability that allows remote attackers to terminate service components by sending a crafted HTTP GET request to the management server on port 9091. Attackers can exploit the unprotected /management/stop endpoint, which bypasses REST API authentication middleware, by supplying a 'role' parameter to shut down the proxy, datanode, or querynode components, resulting in denial of service.