CWE-319
AllowedCleartext Transmission of Sensitive Information
Abstraction: Base · Status: Draft
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
1202 vulnerabilities reference this CWE, most recent first.
GHSA-GRMH-8693-2942
Vulnerability from github – Published: 2023-12-07 15:30 – Updated: 2025-11-04 21:30The affected devices transmit sensitive information unencrypted allowing a remote unauthenticated attacker to capture and modify network traffic.
{
"affected": [],
"aliases": [
"CVE-2023-39172"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-07T14:15:07Z",
"severity": "CRITICAL"
},
"details": "The affected devices transmit sensitive information unencrypted allowing a remote unauthenticated attacker to capture and modify network traffic.",
"id": "GHSA-grmh-8693-2942",
"modified": "2025-11-04T21:30:50Z",
"published": "2023-12-07T15:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39172"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2023/Nov/4"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2023/Nov/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GV83-GQW6-9J2C
Vulnerability from github – Published: 2026-07-06 20:43 – Updated: 2026-07-06 20:43Summary
The helmet middleware in gofiber/fiber never sets the Strict-Transport-Security (HSTS) response header, even when HSTSMaxAge is explicitly configured, because the condition check at helmet.go:67 uses c.Protocol() — which returns the HTTP protocol version string (e.g., "HTTP/1.1", "HTTP/2.0") — instead of c.Scheme() — which returns the URL scheme ("http" or "https"). Since c.Protocol() never equals "https" in any real deployment, the HSTS header is permanently disabled, defeating the security protection.
Details
Root cause: middleware/helmet/helmet.go, line 67:
if c.Protocol() == "https" && cfg.HSTSMaxAge != 0 {
c.Protocol() (defined at req.go:865-867) delegates to fasthttp.Request.Header.Protocol(), which returns the HTTP protocol version:
- "HTTP/1.1" for HTTP/1.1 connections
- "HTTP/2.0" for HTTP/2 connections
The correct method is c.Scheme() (defined at req.go:844-862), which returns:
- "http" for plain HTTP connections
- "https" for TLS connections
Since "HTTP/1.1" != "https" always evaluates to true, the entire HSTS block (lines 67-76) is dead code.
Note on test coverage: The existing helmet test (helmet_test.go) passes because it uses ctx.Request.Header.SetProtocol("https") to artificially force Protocol() to return "https". However, fasthttp.Request.Header.SetProtocol() sets the HTTP version field, and real HTTP requests never have protocol "https" — they have "HTTP/1.1" or "HTTP/2.0". The test is validating the wrong thing.
PoC
Clean-checkout maintainer-runnable recipe:
- Save the following as
middleware/helmet/poc_hsts_test.go:
package helmet
import (
"crypto/tls"
"net/http/httptest"
"testing"
"github.com/gofiber/fiber/v3"
)
func Test_PoC_HSTS_NeverSet(t *testing.T) {
app := fiber.New()
app.Use(New(Config{
HSTSMaxAge: 31536000,
}))
app.Get("/", func(c fiber.Ctx) error {
return c.SendString("ok")
})
// Simulate HTTPS connection
req := httptest.NewRequest(fiber.MethodGet, "/", nil)
req.TLS = &tls.ConnectionState{}
resp, _ := app.Test(req)
hsts := resp.Header.Get("Strict-Transport-Security")
if hsts == "" {
t.Log("BUG CONFIRMED: HSTS header not set. c.Protocol() returns 'HTTP/1.1', not 'https'")
t.Log("Fix: change c.Protocol() == 'https' to c.Scheme() == 'https' on line 67")
}
}
- Run:
go test -run Test_PoC_HSTS_NeverSet -v ./middleware/helmet/
Expected vulnerable output:
=== RUN Test_PoC_HSTS_NeverSet
BUG CONFIRMED: HSTS header not set. c.Protocol() returns 'HTTP/1.1', not 'https'
Fix: change c.Protocol() == 'https' to c.Scheme() == 'https' on line 67
--- PASS: Test_PoC_HSTS_NeverSet
Expected output after fix:
=== RUN Test_PoC_HSTS_NeverSet
--- PASS: Test_PoC_HSTS_NeverSet
(HSTS header is set: "max-age=31536000; includeSubDomains")
Observed output from this environment (commit ee98695f):
=== RUN Test_PoC_HSTS_NeverSet
poc_hsts_test.go:39: HSTS header value: ""
poc_hsts_test.go:42: BUG CONFIRMED: HSTS header is NOT set even over TLS
poc_hsts_test.go:43: Root cause: helmet.go:67 uses c.Protocol() which returns HTTP version
poc_hsts_test.go:44: c.Protocol() returns 'HTTP/1.1' not 'https'
poc_hsts_test.go:45: Fix: use c.Scheme() == 'https' instead of c.Protocol() == 'https'
--- PASS: Test_PoC_HSTS_NeverSet
Negative/control case: With HSTSMaxAge: 0 (default), HSTS is correctly not set (this is expected behavior, not a bug).
Cleanup: Remove poc_hsts_test.go after verification.
Impact
The HSTS header is never applied in production, leaving all users vulnerable to:
- SSL stripping attacks: An active network attacker can downgrade HTTPS connections to HTTP, intercepting traffic between the client and server.
- Protocol downgrade: Without HSTS, browsers will silently accept HTTP connections to the site, even if the site supports HTTPS.
- Cookie theft over HTTP: Session cookies without the Secure flag will be sent over HTTP if the user is tricked into an HTTP connection.
This affects any application that:
1. Uses the helmet middleware
2. Configures HSTSMaxAge > 0 expecting HSTS protection
3. Serves traffic over HTTPS
The vulnerability requires an active MITM attacker on the network path, which is realistic in public Wi-Fi, corporate networks, and ISP-level scenarios.
Suggested remediation
In middleware/helmet/helmet.go, line 67, replace c.Protocol() with c.Scheme():
// Before (broken):
if c.Protocol() == "https" && cfg.HSTSMaxAge != 0 {
// After (fixed):
if c.Scheme() == "https" && cfg.HSTSMaxAge != 0 {
Additionally, update the existing test to use a realistic TLS simulation instead of SetProtocol("https"):
// Before (artificial - sets HTTP version to "https" which never happens in practice):
ctx.Request.Header.SetProtocol("https")
// After (realistic - simulates TLS connection):
ctx.RequestCtx().Request.Header.SetProtocol("HTTP/1.1")
ctx.RequestCtx().TLS = &tls.ConnectionState{}
Regression test: Add a test case that verifies HSTS is set when req.TLS is non-nil and HSTSMaxAge > 0, without using SetProtocol.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.3.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/gofiber/fiber"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53624"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:43:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `helmet` middleware in gofiber/fiber never sets the `Strict-Transport-Security` (HSTS) response header, even when `HSTSMaxAge` is explicitly configured, because the condition check at `helmet.go:67` uses `c.Protocol()` \u2014 which returns the HTTP protocol version string (e.g., `\"HTTP/1.1\"`, `\"HTTP/2.0\"`) \u2014 instead of `c.Scheme()` \u2014 which returns the URL scheme (`\"http\"` or `\"https\"`). Since `c.Protocol()` never equals `\"https\"` in any real deployment, the HSTS header is permanently disabled, defeating the security protection.\n\n### Details\n\n**Root cause:** `middleware/helmet/helmet.go`, line 67:\n\n```go\nif c.Protocol() == \"https\" \u0026\u0026 cfg.HSTSMaxAge != 0 {\n```\n\n`c.Protocol()` (defined at `req.go:865-867`) delegates to `fasthttp.Request.Header.Protocol()`, which returns the HTTP protocol version:\n- `\"HTTP/1.1\"` for HTTP/1.1 connections\n- `\"HTTP/2.0\"` for HTTP/2 connections\n\nThe correct method is `c.Scheme()` (defined at `req.go:844-862`), which returns:\n- `\"http\"` for plain HTTP connections\n- `\"https\"` for TLS connections\n\nSince `\"HTTP/1.1\" != \"https\"` always evaluates to `true`, the entire HSTS block (lines 67-76) is dead code.\n\n**Note on test coverage:** The existing helmet test (`helmet_test.go`) passes because it uses `ctx.Request.Header.SetProtocol(\"https\")` to artificially force `Protocol()` to return `\"https\"`. However, `fasthttp.Request.Header.SetProtocol()` sets the HTTP version field, and real HTTP requests never have protocol `\"https\"` \u2014 they have `\"HTTP/1.1\"` or `\"HTTP/2.0\"`. The test is validating the wrong thing.\n\n### PoC\n\n**Clean-checkout maintainer-runnable recipe:**\n\n1. Save the following as `middleware/helmet/poc_hsts_test.go`:\n\n```go\npackage helmet\n\nimport (\n \"crypto/tls\"\n \"net/http/httptest\"\n \"testing\"\n\n \"github.com/gofiber/fiber/v3\"\n)\n\nfunc Test_PoC_HSTS_NeverSet(t *testing.T) {\n app := fiber.New()\n app.Use(New(Config{\n HSTSMaxAge: 31536000,\n }))\n app.Get(\"/\", func(c fiber.Ctx) error {\n return c.SendString(\"ok\")\n })\n\n // Simulate HTTPS connection\n req := httptest.NewRequest(fiber.MethodGet, \"/\", nil)\n req.TLS = \u0026tls.ConnectionState{}\n\n resp, _ := app.Test(req)\n hsts := resp.Header.Get(\"Strict-Transport-Security\")\n\n if hsts == \"\" {\n t.Log(\"BUG CONFIRMED: HSTS header not set. c.Protocol() returns \u0027HTTP/1.1\u0027, not \u0027https\u0027\")\n t.Log(\"Fix: change c.Protocol() == \u0027https\u0027 to c.Scheme() == \u0027https\u0027 on line 67\")\n }\n}\n```\n\n2. Run: `go test -run Test_PoC_HSTS_NeverSet -v ./middleware/helmet/`\n\n**Expected vulnerable output:**\n```\n=== RUN Test_PoC_HSTS_NeverSet\n BUG CONFIRMED: HSTS header not set. c.Protocol() returns \u0027HTTP/1.1\u0027, not \u0027https\u0027\n Fix: change c.Protocol() == \u0027https\u0027 to c.Scheme() == \u0027https\u0027 on line 67\n--- PASS: Test_PoC_HSTS_NeverSet\n```\n\n**Expected output after fix:**\n```\n=== RUN Test_PoC_HSTS_NeverSet\n--- PASS: Test_PoC_HSTS_NeverSet\n (HSTS header is set: \"max-age=31536000; includeSubDomains\")\n```\n\n**Observed output from this environment (commit `ee98695f`):**\n```\n=== RUN Test_PoC_HSTS_NeverSet\n poc_hsts_test.go:39: HSTS header value: \"\"\n poc_hsts_test.go:42: BUG CONFIRMED: HSTS header is NOT set even over TLS\n poc_hsts_test.go:43: Root cause: helmet.go:67 uses c.Protocol() which returns HTTP version\n poc_hsts_test.go:44: c.Protocol() returns \u0027HTTP/1.1\u0027 not \u0027https\u0027\n poc_hsts_test.go:45: Fix: use c.Scheme() == \u0027https\u0027 instead of c.Protocol() == \u0027https\u0027\n--- PASS: Test_PoC_HSTS_NeverSet\n```\n\n**Negative/control case:** With `HSTSMaxAge: 0` (default), HSTS is correctly not set (this is expected behavior, not a bug).\n\n**Cleanup:** Remove `poc_hsts_test.go` after verification.\n\n### Impact\n\nThe HSTS header is never applied in production, leaving all users vulnerable to:\n- **SSL stripping attacks:** An active network attacker can downgrade HTTPS connections to HTTP, intercepting traffic between the client and server.\n- **Protocol downgrade:** Without HSTS, browsers will silently accept HTTP connections to the site, even if the site supports HTTPS.\n- **Cookie theft over HTTP:** Session cookies without the `Secure` flag will be sent over HTTP if the user is tricked into an HTTP connection.\n\nThis affects any application that:\n1. Uses the `helmet` middleware\n2. Configures `HSTSMaxAge \u003e 0` expecting HSTS protection\n3. Serves traffic over HTTPS\n\nThe vulnerability requires an active MITM attacker on the network path, which is realistic in public Wi-Fi, corporate networks, and ISP-level scenarios.\n\n### Suggested remediation\n\nIn `middleware/helmet/helmet.go`, line 67, replace `c.Protocol()` with `c.Scheme()`:\n\n```go\n// Before (broken):\nif c.Protocol() == \"https\" \u0026\u0026 cfg.HSTSMaxAge != 0 {\n\n// After (fixed):\nif c.Scheme() == \"https\" \u0026\u0026 cfg.HSTSMaxAge != 0 {\n```\n\nAdditionally, update the existing test to use a realistic TLS simulation instead of `SetProtocol(\"https\")`:\n\n```go\n// Before (artificial - sets HTTP version to \"https\" which never happens in practice):\nctx.Request.Header.SetProtocol(\"https\")\n\n// After (realistic - simulates TLS connection):\nctx.RequestCtx().Request.Header.SetProtocol(\"HTTP/1.1\")\nctx.RequestCtx().TLS = \u0026tls.ConnectionState{}\n```\n\n**Regression test:** Add a test case that verifies HSTS is set when `req.TLS` is non-nil and `HSTSMaxAge \u003e 0`, without using `SetProtocol`.",
"id": "GHSA-gv83-gqw6-9j2c",
"modified": "2026-07-06T20:43:12Z",
"published": "2026-07-06T20:43:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gofiber/fiber/security/advisories/GHSA-gv83-gqw6-9j2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/gofiber/fiber"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "GoFiber never set HSTS header in helmet middleware due to incorrect protocol check"
}
GHSA-GVCJ-72H4-8XM9
Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2023-01-06 16:58Quality Gates Plugin stores credentials in its global configuration file quality.gates.jenkins.plugin.GlobalConfig.xml on the Jenkins controller as part of its configuration. While the credentials are stored encrypted on disk, they are transmitted in plain text as part of the configuration form by Quality Gates Plugin 2.5 and earlier. This can result in exposure of the credential through browser extensions, cross-site scripting vulnerabilities, and similar situations.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:quality-gates"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-2151"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-06T16:58:54Z",
"nvd_published_at": "2020-03-09T16:15:00Z",
"severity": "LOW"
},
"details": "Quality Gates Plugin stores credentials in its global configuration file `quality.gates.jenkins.plugin.GlobalConfig.xml` on the Jenkins controller as part of its configuration. While the credentials are stored encrypted on disk, they are transmitted in plain text as part of the configuration form by Quality Gates Plugin 2.5 and earlier. This can result in exposure of the credential through browser extensions, cross-site scripting vulnerabilities, and similar situations.",
"id": "GHSA-gvcj-72h4-8xm9",
"modified": "2023-01-06T16:58:54Z",
"published": "2022-05-24T17:10:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2151"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/quality-gates-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1519"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/03/09/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Quality Gates Plugin transmits credentials in plain text during configuration "
}
GHSA-GWQ5-325P-3VVH
Vulnerability from github – Published: 2025-01-13 00:30 – Updated: 2025-01-13 00:30HCL MyXalytics is affected by a cleartext transmission of sensitive information vulnerability. The application transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
{
"affected": [],
"aliases": [
"CVE-2024-42181"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-12T22:15:07Z",
"severity": "LOW"
},
"details": "HCL MyXalytics is affected by a cleartext transmission of sensitive information vulnerability. The application transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.",
"id": "GHSA-gwq5-325p-3vvh",
"modified": "2025-01-13T00:30:54Z",
"published": "2025-01-13T00:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42181"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118149"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GX4C-2HQX-CW2R
Vulnerability from github – Published: 2026-08-05 20:43 – Updated: 2026-08-05 20:43Vulnerability Details
File: backend/s3/s3.go
Lines: 1359-1380 (functions s3CheckRedirect / s3RedirectCrossesHost)
Root Cause
Commit e7b1eb774 (released in v1.74.3) added a CheckRedirect policy for
the S3 HTTP client whose purpose is to strip the X-Amz-Security-Token
header (the AWS STS session token) whenever a redirect chain "crosses a
host", so the token isn't forwarded to an unintended origin.
s3RedirectCrossesHost decides this purely by comparing url.URL.Host
(hostname[:port]); it never looks at url.URL.Scheme. A redirect that keeps
the exact same host:port but changes the scheme from https:// to http://
therefore compares as "same host" and X-Amz-Security-Token is not
stripped — it is sent again, this time over plaintext HTTP.
func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
if len(via) == 0 {
return false
}
host := via[0].URL.Host
for _, redirect := range via[1:] {
if redirect.URL.Host != host {
return true
}
}
return host != req.URL.Host
}
Attack Scenario
- The user configures an
s3remote (or--s3-endpointpointing at a self-hosted/third-party S3-compatible service) using temporary credentials that include an STSsession_token(common for assumed-role / CI / Kubernetes IRSA setups). - The configured endpoint responds to a request with a 3xx redirect to the
same host:port but with
http://instead ofhttps://(TLS-front misconfiguration, maintenance redirect, or a malicious/compromised storage provider trying to harvest the token). - rclone's S3 HTTP client follows the redirect and re-sends the request,
including
X-Amz-Security-Token, over the now-unencrypted connection to that same host. - Any passive observer on that now-plaintext network path can read the STS session token from the request headers.
Impact
Disclosure of the AWS STS session token (X-Amz-Security-Token) in
cleartext for the remainder of its validity window. This is the exact class
of leak that e7b1eb774 was written to close — it just doesn't cover the
scheme-downgrade axis of "crossing a host".
Vulnerable Code
func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
if len(via) == 0 {
return false
}
host := via[0].URL.Host
for _, redirect := range via[1:] {
if redirect.URL.Host != host {
return true
}
}
return host != req.URL.Host
}
Recommended Fix
Also compare URL.Scheme, so a scheme downgrade on the same host is treated
the same as a host change:
func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
if len(via) == 0 {
return false
}
scheme, host := via[0].URL.Scheme, via[0].URL.Host
for _, redirect := range via[1:] {
if redirect.URL.Host != host || redirect.URL.Scheme != scheme {
return true
}
}
return host != req.URL.Host || scheme != req.URL.Scheme
}
Verification
Added a unit test (backend/s3/redirect_scheme_test.go) that calls the real,
unmodified s3RedirectCrossesHost / s3CheckRedirect with an
https://bucket.example.com -> http://bucket.example.com redirect chain.
On unpatched code (commit 16091ce365, current master / v1.74.3):
- s3RedirectCrossesHost returns false
- s3CheckRedirect leaves X-Amz-Security-Token: SECRET-SESSION-TOKEN
intact on the outgoing (plaintext) request.
=== RUN TestSchemeDowngradeNotDetectedAsCrossHost
redirect_scheme_test.go:23: initial=https://bucket.example.com final=http://bucket.example.com s3RedirectCrossesHost=false
--- PASS: TestSchemeDowngradeNotDetectedAsCrossHost (0.00s)
After applying the one-line fix above (also adding scheme comparison), the
token is correctly stripped and all existing redirect tests
(TestClientRemovesSecurityTokenOnCrossHostRedirect,
TestClientDoesNotRestoreSecurityTokenAfterCrossHostRedirect,
TestClientKeepsSecurityTokenOnSameHostRedirect,
TestClientStopsAfterTenRedirects) continue to pass.
A minimal fix commit is ready and can be pushed to a private fork once this report is acknowledged.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.74.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.74.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-05T20:43:11Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Vulnerability Details\n\n**File**: `backend/s3/s3.go`\n**Lines**: 1359-1380 (functions `s3CheckRedirect` / `s3RedirectCrossesHost`)\n\n### Root Cause\nCommit `e7b1eb774` (released in v1.74.3) added a `CheckRedirect` policy for\nthe S3 HTTP client whose purpose is to strip the `X-Amz-Security-Token`\nheader (the AWS STS session token) whenever a redirect chain \"crosses a\nhost\", so the token isn\u0027t forwarded to an unintended origin.\n\n`s3RedirectCrossesHost` decides this purely by comparing `url.URL.Host`\n(hostname[:port]); it never looks at `url.URL.Scheme`. A redirect that keeps\nthe exact same host:port but changes the scheme from `https://` to `http://`\ntherefore compares as \"same host\" and `X-Amz-Security-Token` is *not*\nstripped \u2014 it is sent again, this time over plaintext HTTP.\n\n```go\nfunc s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {\n\tif len(via) == 0 {\n\t\treturn false\n\t}\n\thost := via[0].URL.Host\n\tfor _, redirect := range via[1:] {\n\t\tif redirect.URL.Host != host {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn host != req.URL.Host\n}\n```\n\n### Attack Scenario\n1. The user configures an `s3` remote (or `--s3-endpoint` pointing at a\n self-hosted/third-party S3-compatible service) using temporary\n credentials that include an STS `session_token` (common for assumed-role\n / CI / Kubernetes IRSA setups).\n2. The configured endpoint responds to a request with a 3xx redirect to the\n *same* host:port but with `http://` instead of `https://` (TLS-front\n misconfiguration, maintenance redirect, or a malicious/compromised\n storage provider trying to harvest the token).\n3. rclone\u0027s S3 HTTP client follows the redirect and re-sends the request,\n including `X-Amz-Security-Token`, over the now-unencrypted connection to\n that same host.\n4. Any passive observer on that now-plaintext network path can read the STS\n session token from the request headers.\n\n### Impact\nDisclosure of the AWS STS session token (`X-Amz-Security-Token`) in\ncleartext for the remainder of its validity window. This is the exact class\nof leak that `e7b1eb774` was written to close \u2014 it just doesn\u0027t cover the\nscheme-downgrade axis of \"crossing a host\".\n\n### Vulnerable Code\n```go\nfunc s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {\n\tif len(via) == 0 {\n\t\treturn false\n\t}\n\thost := via[0].URL.Host\n\tfor _, redirect := range via[1:] {\n\t\tif redirect.URL.Host != host {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn host != req.URL.Host\n}\n```\n\n### Recommended Fix\nAlso compare `URL.Scheme`, so a scheme downgrade on the same host is treated\nthe same as a host change:\n\n```go\nfunc s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {\n\tif len(via) == 0 {\n\t\treturn false\n\t}\n\tscheme, host := via[0].URL.Scheme, via[0].URL.Host\n\tfor _, redirect := range via[1:] {\n\t\tif redirect.URL.Host != host || redirect.URL.Scheme != scheme {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn host != req.URL.Host || scheme != req.URL.Scheme\n}\n```\n\n### Verification\nAdded a unit test (`backend/s3/redirect_scheme_test.go`) that calls the real,\nunmodified `s3RedirectCrossesHost` / `s3CheckRedirect` with an\n`https://bucket.example.com` -\u003e `http://bucket.example.com` redirect chain.\n\nOn unpatched code (commit 16091ce365, current master / v1.74.3):\n- `s3RedirectCrossesHost` returns `false`\n- `s3CheckRedirect` leaves `X-Amz-Security-Token: SECRET-SESSION-TOKEN`\n intact on the outgoing (plaintext) request.\n\n```\n=== RUN TestSchemeDowngradeNotDetectedAsCrossHost\n redirect_scheme_test.go:23: initial=https://bucket.example.com final=http://bucket.example.com s3RedirectCrossesHost=false\n--- PASS: TestSchemeDowngradeNotDetectedAsCrossHost (0.00s)\n```\n\nAfter applying the one-line fix above (also adding scheme comparison), the\ntoken is correctly stripped and all existing redirect tests\n(`TestClientRemovesSecurityTokenOnCrossHostRedirect`,\n`TestClientDoesNotRestoreSecurityTokenAfterCrossHostRedirect`,\n`TestClientKeepsSecurityTokenOnSameHostRedirect`,\n`TestClientStopsAfterTenRedirects`) continue to pass.\n\nA minimal fix commit is ready and can be pushed to a private fork once this\nreport is acknowledged.",
"id": "GHSA-gx4c-2hqx-cw2r",
"modified": "2026-08-05T20:43:11Z",
"published": "2026-08-05T20:43:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-gx4c-2hqx-cw2r"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/commit/1a28451ea6fc8ac1806b0e9923dcb5b3f543f7fa"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/releases/tag/v1.74.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "rclone: S3 backend does not strip X-Amz-Security-Token on a same-host HTTPS-\u003eHTTP redirect"
}
GHSA-GXPM-63FR-38V5
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02An issue was discovered in Couchbase Server 6.x through 6.6.1. The Couchbase Server UI is insecurely logging session cookies in the logs. This allows for the impersonation of a user if the log files are obtained by an attacker before a session cookie expires.
{
"affected": [],
"aliases": [
"CVE-2021-27924"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-19T20:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Couchbase Server 6.x through 6.6.1. The Couchbase Server UI is insecurely logging session cookies in the logs. This allows for the impersonation of a user if the log files are obtained by an attacker before a session cookie expires.",
"id": "GHSA-gxpm-63fr-38v5",
"modified": "2022-05-24T19:02:45Z",
"published": "2022-05-24T19:02:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27924"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/downloads"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/resources/security#SecurityAlerts"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-H237-F2VG-F29Q
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37The built-in WEB server for MOXA NPort IAW5000A-I/O firmware version 2.1 or lower stores and transmits the credentials of third-party services in cleartext.
{
"affected": [],
"aliases": [
"CVE-2020-25190"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-23T15:15:00Z",
"severity": "CRITICAL"
},
"details": "The built-in WEB server for MOXA NPort IAW5000A-I/O firmware version 2.1 or lower stores and transmits the credentials of third-party services in cleartext.",
"id": "GHSA-h237-f2vg-f29q",
"modified": "2022-05-24T17:37:04Z",
"published": "2022-05-24T17:37:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25190"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-287-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-H2C2-GC59-R4J2
Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2023-01-30 21:30IBM API Connect 5.0.0.0 through 5.0.8.6 could allow an unauthorized user to obtain sensitive information about the system users using specially crafted HTTP requests. IBM X-Force ID: 162162.
{
"affected": [],
"aliases": [
"CVE-2019-4382"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-25T16:15:00Z",
"severity": "MODERATE"
},
"details": "IBM API Connect 5.0.0.0 through 5.0.8.6 could allow an unauthorized user to obtain sensitive information about the system users using specially crafted HTTP requests. IBM X-Force ID: 162162.",
"id": "GHSA-h2c2-gc59-r4j2",
"modified": "2023-01-30T21:30:43Z",
"published": "2022-05-24T22:00:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4382"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/162162"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/docview.wss?uid=ibm10886747"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108893"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H2V9-XPQQ-69HX
Vulnerability from github – Published: 2026-04-20 18:31 – Updated: 2026-04-20 18:31ConnectWise has released a security update for ConnectWise Automate™ that addresses a behavior in the ConnectWise Automate Solution Center where certain client-to-server communications could occur without transport-layer encryption. This could allow network‑based interception of Solution Center traffic in Automate deployments. The issue has been resolved in Automate 2026.4 by enforcing secure communication for affected Solution Center connections.
{
"affected": [],
"aliases": [
"CVE-2026-6066"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-20T16:16:50Z",
"severity": "HIGH"
},
"details": "ConnectWise has released a security update for ConnectWise Automate\u2122 that addresses a behavior in the ConnectWise Automate Solution Center where certain client-to-server communications could occur without transport-layer encryption. This could allow network\u2011based interception of Solution Center traffic in Automate deployments. The issue has been resolved in Automate 2026.4 by enforcing secure communication for affected Solution Center connections.",
"id": "GHSA-h2v9-xpqq-69hx",
"modified": "2026-04-20T18:31:48Z",
"published": "2026-04-20T18:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6066"
},
{
"type": "WEB",
"url": "https://www.connectwise.com/company/trust/security-bulletins/2026-04-20-connectwise-automate-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H2XX-8RQ3-G9G2
Vulnerability from github – Published: 2026-05-27 09:31 – Updated: 2026-05-27 09:31Cleartext transmission of sensitive information vulnerability in Export Key functionality in Synology Surveillance Station before 9.2.2-11575 and 9.2.2-9575 allows remote authenticated users with administrator privileges to obtain sensitive information via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2024-47269"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T09:16:25Z",
"severity": "MODERATE"
},
"details": "Cleartext transmission of sensitive information vulnerability in Export Key functionality in Synology Surveillance Station before 9.2.2-11575 and 9.2.2-9575 allows remote authenticated users with administrator privileges to obtain sensitive information via unspecified vectors.",
"id": "GHSA-h2xx-8rq3-g9g2",
"modified": "2026-05-27T09:31:16Z",
"published": "2026-05-27T09:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47269"
},
{
"type": "WEB",
"url": "https://www.synology.com/en-global/security/advisory/Synology_SA_24_25"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.
Mitigation
When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.
Mitigation
When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.
Mitigation
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
Mitigation
Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-117: Interception
An adversary monitors data streams to or from the target for information gathering purposes. This attack may be undertaken to solely gather sensitive information or to support a further attack against the target. This attack pattern can involve sniffing network traffic as well as other types of data streams (e.g. radio). The adversary can attempt to initiate the establishment of a data stream or passively observe the communications as they unfold. In all variants of this attack, the adversary is not the intended recipient of the data stream. In contrast to other means of gathering information (e.g., targeting data leaks), the adversary must actively position themself so as to observe explicit data channels (e.g. network traffic) and read the content. However, this attack differs from a Adversary-In-the-Middle (CAPEC-94) attack, as the adversary does not alter the content of the communications nor forward data to the intended recipient.
CAPEC-383: Harvesting Information via API Event Monitoring
An adversary hosts an event within an application framework and then monitors the data exchanged during the course of the event for the purpose of harvesting any important data leaked during the transactions. One example could be harvesting lists of usernames or userIDs for the purpose of sending spam messages to those users. One example of this type of attack involves the adversary creating an event within the sub-application. Assume the adversary hosts a "virtual sale" of rare items. As other users enter the event, the attacker records via AiTM (CAPEC-94) proxy the user_ids and usernames of everyone who attends. The adversary would then be able to spam those users within the application using an automated script.
CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content
An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.
CAPEC-65: Sniff Application Code
An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.