Improper neutralization of argument delimiters in a command ('argument injection') vulnerability in TUBITAK BILGEM Software Technologies Research Institute Pardus Pen allows Argument Injection.

This issue affects Pardus Pen: before 4.2.1.

In PCRE2 before 10.48, pcre2serializeencode might disclose two bytes to an adversary, typically in a situation where the access available to the adversary is already unsafe.

PCRE2 before 10.48 has a pcre2match out-of-bounds read during the PCRE2MATCHINVALIDUTF matching of an invalid UTF subject.

PCRE2 before 10.48 has a pcre2match out-of-bounds read after a JIT fallback when an attacker can provide invalid UTF data.

Forgejo before 16.0.4 allows use of restricted API tokens for unintended access to the "allow maintainer edit" feature.

strongSwan 4.2.0 through 6.0.7 has a missing release of memory after its effective lifetime in the x509 plugin's attribute certificate parser.

libcharon in strongSwan 4.1.2 through 6.0.7 has a missing release of memory after its effective lifetime in the IKE message parser.

strongSwan 5.0.2 through 6.0.7 allows PKCS#7 certificate enumeration in the openssl plugin that leads to a lack of release of memory after its effective lifetime.

Vulnerability Details

File: backend/http/http.go Lines: 285 (client construction — no CheckRedirect), 505-510 (addHeaders, writes configured secret headers onto every request), 533-534 / 700-701 / 782-785 (f.httpClient.Do(req) used by List/stat/download)

Root Cause The http backend lets a user attach arbitrary secret headers to every request via --http-headers/headers= (documented for authentication: '"Cookie","name=value","Authorization","xxx"'). The backend's HTTP client is built with fshttp.NewClient(ctx), which never sets http.Client.CheckRedirect, so it falls back to Go's stdlib default redirect policy.

Go's default policy only strips four header names (Authorization, Www-Authenticate, Cookie, Cookie2), and only when the redirect target's host differs from the original — every other configured header is copied to the redirect target unconditionally, regardless of host or scheme. Even the four protected names survive a same-host https:// → http:// downgrade, since Go only checks host equality, not scheme.

Any redirect response from the configured remote — whether from server compromise, an open redirect, a CDN/mirror failover to a different domain, or a malicious server from the start — causes rclone to resend every configured secret header (and, for a scheme downgrade, Authorization/Cookie in cleartext) to the new destination.

This is the exact vulnerability class already fixed for the s3 backend (9328763/7543a7a, GHSA-8mxv-9xhp-86h4 and the webdav backend (59b513b, GHSA-h4mf-4v27-hggj, wiring rest.RefuseHTTPSDowngradeRedirectFn). backend/http was not touched by either fix.

Vulnerable Code go // backend/http/http.go:285 client := fshttp.NewClient(ctx) // no CheckRedirect set ... f.httpClient = client // used by readDir / NewObject / Object.Open go // backend/http/http.go:505-510 func addHeaders(req http.Request, opt Options) { for i := 0; i < len(opt.Headers); i += 2 { key := opt.Headers[i] value := opt.Headers[i+1] req.Header.Add(key, value) } }

Attack Scenario 1. User configures an http remote: url=https://good.example.com/files/, headers=X-Api-Key,SECRET-TOKEN. 2. At some point good.example.com returns a redirect whose Location points at a different host (compromise, open redirect, CDN change, or malice from the start). 3. User runs any operation (ls, cat, copy, mount, serve) against the remote. 4. rclone follows the redirect with the default client and resends X-Api-Key: SECRET-TOKEN to the new, untrusted destination. 5. The attacker's server captures the secret from the incoming request.

Impact Exfiltration of API keys / bearer tokens / session cookies configured for one host, to any host the (trusted-at-configuration-time) remote later redirects to. All operations on the http backend (list, stat, download, mount, serve) are affected. No special rclone privileges or unusual user interaction are needed beyond a normal sync/list/copy once the redirect exists.

Dynamic Confirmation Built rclone from source at cfdc9d0 (current master, v1.76.0-DEV) and configured: ini [testhttp] type = http url = http://127.0.0.1:9090/ headers = X-Api-Key,SUPER-SECRET-TOKEN-abc123 Server A (port 9090, the "configured" host) 302-redirects every request to Server B (port 9091, a different host). Running rclone cat testhttp:file.txt caused Server B — which was never configured with any credential — to receive: Header: X-Api-Key: SUPER-SECRET-TOKEN-abc123 Header: Referer: http://127.0.0.1:9090/file.txt rclone printed Server B's response body as if it were the real file, confirming the full stat→redirect→download round trip leaks the header and trusts the redirect target.

Vulnerable Code / Fix A minimal fix (implemented, tested, and verified to close the leak while preserving redirect functionality) wires the client to rest.RefuseHTTPSDowngradeRedirectFn (already used by webdav) and strips the configured opt.Headers on any cross-host redirect:

go client := fshttp.NewClient(ctx) client.CheckRedirect = redirectCheckFn(opt) ... func redirectCheckFn(opt Options) func(req http.Request, via []http.Request) error { return func(req http.Request, via []http.Request) error { if err := rest.RefuseHTTPSDowngradeRedirectFn(req, via); err != nil { return err } if len(via) > 0 && req.URL.Host != via[0].URL.Host { for i := 0; i < len(opt.Headers); i += 2 { req.Header.Del(opt.Headers[i]) } } return nil } }

A regression test (TestRedirectStripsHeadersOnHostChange) was added to backend/http/httpinternaltest.go, confirmed to fail without the fix and pass with it. Full backend/http and lib/rest test suites pass with the fix applied. I have a fix branch ready to push to a private fork once this report is acknowledged.

Verification Dynamically confirmed on rclone master @ cfdc9d0 (post v1.75.0) in a local test harness — see "Dynamic Confirmation" above. Fix verified to eliminate the leak via the same harness (secret header absent from Server B after the fix; functionality — file download via redirect — unaffected).

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 crafted rule using mixed-case frame syntax could trigger a heap buffer overflow while Suricata is loading signatures. The issue is reached during rule parsing/loading rather than by network traffic alone. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, preprocess rules to check that frames are all lowercase and/or only load trusted rulesets.

Vulnerability Details

File: backend/http/http.go Lines: 285 (client construction — no CheckRedirect), 505-510 (addHeaders, writes configured secret headers onto every request), 533-534 / 700-701 / 782-785 (f.httpClient.Do(req) used by List/stat/download)

Root Cause The http backend lets a user attach arbitrary secret headers to every request via --http-headers/headers= (documented for authentication: '"Cookie","name=value","Authorization","xxx"'). The backend's HTTP client is built with fshttp.NewClient(ctx), which never sets http.Client.CheckRedirect, so it falls back to Go's stdlib default redirect policy.

Go's default policy only strips four header names (Authorization, Www-Authenticate, Cookie, Cookie2), and only when the redirect target's host differs from the original — every other configured header is copied to the redirect target unconditionally, regardless of host or scheme. Even the four protected names survive a same-host https:// → http:// downgrade, since Go only checks host equality, not scheme.

Any redirect response from the configured remote — whether from server compromise, an open redirect, a CDN/mirror failover to a different domain, or a malicious server from the start — causes rclone to resend every configured secret header (and, for a scheme downgrade, Authorization/Cookie in cleartext) to the new destination.

This is the exact vulnerability class already fixed for the s3 backend (9328763/7543a7a, GHSA-8mxv-9xhp-86h4 and the webdav backend (59b513b, GHSA-h4mf-4v27-hggj, wiring rest.RefuseHTTPSDowngradeRedirectFn). backend/http was not touched by either fix.

Vulnerable Code go // backend/http/http.go:285 client := fshttp.NewClient(ctx) // no CheckRedirect set ... f.httpClient = client // used by readDir / NewObject / Object.Open go // backend/http/http.go:505-510 func addHeaders(req http.Request, opt Options) { for i := 0; i < len(opt.Headers); i += 2 { key := opt.Headers[i] value := opt.Headers[i+1] req.Header.Add(key, value) } }

Attack Scenario 1. User configures an http remote: url=https://good.example.com/files/, headers=X-Api-Key,SECRET-TOKEN. 2. At some point good.example.com returns a redirect whose Location points at a different host (compromise, open redirect, CDN change, or malice from the start). 3. User runs any operation (ls, cat, copy, mount, serve) against the remote. 4. rclone follows the redirect with the default client and resends X-Api-Key: SECRET-TOKEN to the new, untrusted destination. 5. The attacker's server captures the secret from the incoming request.

Impact Exfiltration of API keys / bearer tokens / session cookies configured for one host, to any host the (trusted-at-configuration-time) remote later redirects to. All operations on the http backend (list, stat, download, mount, serve) are affected. No special rclone privileges or unusual user interaction are needed beyond a normal sync/list/copy once the redirect exists.

Dynamic Confirmation Built rclone from source at cfdc9d0 (current master, v1.76.0-DEV) and configured: ini [testhttp] type = http url = http://127.0.0.1:9090/ headers = X-Api-Key,SUPER-SECRET-TOKEN-abc123 Server A (port 9090, the "configured" host) 302-redirects every request to Server B (port 9091, a different host). Running rclone cat testhttp:file.txt caused Server B — which was never configured with any credential — to receive: Header: X-Api-Key: SUPER-SECRET-TOKEN-abc123 Header: Referer: http://127.0.0.1:9090/file.txt rclone printed Server B's response body as if it were the real file, confirming the full stat→redirect→download round trip leaks the header and trusts the redirect target.

Vulnerable Code / Fix A minimal fix (implemented, tested, and verified to close the leak while preserving redirect functionality) wires the client to rest.RefuseHTTPSDowngradeRedirectFn (already used by webdav) and strips the configured opt.Headers on any cross-host redirect:

go client := fshttp.NewClient(ctx) client.CheckRedirect = redirectCheckFn(opt) ... func redirectCheckFn(opt Options) func(req http.Request, via []http.Request) error { return func(req http.Request, via []http.Request) error { if err := rest.RefuseHTTPSDowngradeRedirectFn(req, via); err != nil { return err } if len(via) > 0 && req.URL.Host != via[0].URL.Host { for i := 0; i < len(opt.Headers); i += 2 { req.Header.Del(opt.Headers[i]) } } return nil } }

A regression test (TestRedirectStripsHeadersOnHostChange) was added to backend/http/httpinternaltest.go, confirmed to fail without the fix and pass with it. Full backend/http and lib/rest test suites pass with the fix applied. I have a fix branch ready to push to a private fork once this report is acknowledged.

Verification Dynamically confirmed on rclone master @ cfdc9d0 (post v1.75.0) in a local test harness — see "Dynamic Confirmation" above. Fix verified to eliminate the leak via the same harness (secret header absent from Server B after the fix; functionality — file download via redirect — unaffected).

Summary A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC 1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive. 2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">. 3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches - Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds - Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits - Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC 1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive. 2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">. 3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches - Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds - Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits - Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Dell PowerScale OneFS, versions 9.5.0.0 through 9.7.1.15, versions 9.8.0.0 through 9.13.1.0, and versions prior to 9.15.0.0, contain an Incorrect Authorization vulnerability. A low privileged adjacent network attacker could potentially exploit this vulnerability, leading to unauthorized modification of system logs.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains a Least Privilege Violation vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to unauthorized access.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Execution with Unnecessary Privileges vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to unauthorized access.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains a Least Privilege Violation vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to unauthorized access.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access.

Dell Secure Connect Gateway (SCG) 5.0 Appliance, versions prior to 5.36.00.xx, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to protection mechanism bypass.

The OpenPrinting CUPS project contains two instances of case-insensitive username comparisons in authorization-adjacent code paths that were not addressed by the original CVE-2026-27447 fix. These exist in the printer ACL validation logic and private-attribute filtering mechanisms:

1. scheduler/ipp.c:checkquotas() - uses cupsstrcasecmp() for printer ACL username matching 2. scheduler/policy.c:cupsdGetPrivateAttrs() - uses cupsstrcasecmp() for @OWNER and explicit username checks

These patterns were removed from the primary authorization path in the original CVE-2026-27447 fix but persist in these secondary paths.

Affected versions: < 2.4.20. No patched release listed at time of advisory (fixes committed but not yet released).

Reference: https://github.com/OpenPrinting/cups/security/advisories/GHSA-r8jp-q6fh-g5r2

The OpenPrinting CUPS project contains two instances of case-insensitive username comparisons in authorization-adjacent code paths that were not addressed by the original CVE-2026-27447 fix. These exist in the printer ACL validation logic and private-attribute filtering mechanisms:

1. scheduler/ipp.c:checkquotas() - uses cupsstrcasecmp() for printer ACL username matching 2. scheduler/policy.c:cupsdGetPrivateAttrs() - uses cupsstrcasecmp() for @OWNER and explicit username checks

These patterns were removed from the primary authorization path in the original CVE-2026-27447 fix but persist in these secondary paths.

Affected versions: < 2.4.20. No patched release listed at time of advisory (fixes committed but not yet released).

Reference: https://github.com/OpenPrinting/cups/security/advisories/GHSA-r8jp-q6fh-g5r2

Snipe-IT versions >= 7.0.12 and <= 8.6.3 contain an authorization bypass in the Livewire importer component (App\Livewire\Importer, mounted at the imports.index route). The component only checked the broad 'import' ability at mount time, while its files() and activeFile() computed properties queried the imports table with no owner or company scope. As a result, any authenticated non-superuser holding the import permission could view every Import record on the instance (original filename, filepath, filesize, importtype and creation timestamp) and could invoke the selectFile($id) Livewire action with any auto-incrementing Import ID to load another user's record, exposing its stored preview data (headerrow column headers and firstrow, the first data row of the CSV). Because import CSVs commonly contain personal data, asset serial numbers and license keys, this discloses sensitive information; in Full Multiple Companies Support (FMCS) deployments the disclosure also crosses company/tenant boundaries. Impact is limited to preview data rather than the full CSV file, and superusers were unaffected. Fixed in version 8.7.0, which scopes non-superuser reads to imports owned by the caller.

Snipe-IT 8.6.3 and earlier (and develop pre-release commits prior to the fix) contain a race condition in the asset checkout paths. Api\AssetsController::checkout() and Assets\AssetCheckoutController::store() call Asset::availableForCheckout() outside the mutation path and then invoke Asset::checkOut() without taking a row lock or re-checking availability, so two concurrent checkout requests for the same available asset can both observe it as available and both commit. This produces duplicate checkout-history rows, a doubled checkoutcounter, and two CheckoutableCheckedOut events for a single-assignment asset, corrupting the audit trail and utilization/reconciliation reporting; the asset's final assignedto remains singular, so the visible assignment stays intact. Exploitation requires an authenticated session holding the assets.checkout permission (or superuser) and precise concurrent timing. Fixed in 8.7.0.

Snipe-IT before 8.7.0 fails to check the return value of Storage::delete() in UploadedFilesController::destroy() and Api\\UploadedFilesController::destroy(), allowing deletion requests to report success while files remain on disk. Administrators performing attachment deletions receive success responses and see files hidden from listings, but the physical files persist on disk and remain accessible to anyone with filesystem or backup access.

Snipe-IT 8.6.3 and earlier do not check the return value of Storage::put() when writing the signature PNG and the generated acceptance PDF in Account\AcceptanceController::store(). On filesystem drivers that return false instead of throwing on a write failure (for example the local disk with restrictive permissions, S3 with expired credentials, or a storage backend that is out of quota), execution continues into $acceptance->accept(), which sets acceptedat and the signaturefilename/eulafilename fields, creates the 'accepted' action-log entry, and dispatches completion notifications even though the evidence files were never stored. The result is an acceptance record marked complete whose supporting evidence files do not exist, yielding a materially incomplete compliance artifact for EULA acknowledgement or equipment-receipt workflows. The condition is triggered when an authenticated user completes an acceptance while the storage backend is silently failing writes; an attacker cannot directly force the storage backend into that state. Fixed in Snipe-IT 8.7.0.

PocketMine-MP versions before 5.39.2 fail to validate entity despawn state when processing attack packets from clients. Attackers can exploit a race condition by attacking a disconnecting player to trigger multiple death handlers, causing inventory items and experience to drop multiple times for duplication.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.