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.
1148 vulnerabilities reference this CWE, most recent first.
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-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"
}
]
}
GHSA-H44M-7FF4-M8F4
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-05-24 17:45Cleartext transmission of sensitive information in Netop Vision Pro up to and including 9.7.1 allows a remote unauthenticated attacker to gather credentials including Windows login usernames and passwords.
{
"affected": [],
"aliases": [
"CVE-2021-27194"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-25T19:15:00Z",
"severity": "HIGH"
},
"details": "Cleartext transmission of sensitive information in Netop Vision Pro up to and including 9.7.1 allows a remote unauthenticated attacker to gather credentials including Windows login usernames and passwords.",
"id": "GHSA-h44m-7ff4-m8f4",
"modified": "2022-05-24T17:45:25Z",
"published": "2022-05-24T17:45:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27194"
},
{
"type": "WEB",
"url": "https://www.mcafee.com/blogs/other-blogs/mcafee-labs/netop-vision-pro-distance-learning-software-is-20-20-in-hindsight"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-H466-848J-M48V
Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33IBM BigFix Platform 9.2 and 9.5 transmits sensitive or security-critical data in clear text in a communication channel that can be sniffed by unauthorized actors. IBM X-Force ID: 143745.
{
"affected": [],
"aliases": [
"CVE-2018-1600"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-04T17:29:00Z",
"severity": "HIGH"
},
"details": "IBM BigFix Platform 9.2 and 9.5 transmits sensitive or security-critical data in clear text in a communication channel that can be sniffed by unauthorized actors. IBM X-Force ID: 143745.",
"id": "GHSA-h466-848j-m48v",
"modified": "2022-05-13T01:33:05Z",
"published": "2022-05-13T01:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1600"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/143745"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22015754"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/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.