CWE-209
AllowedGeneration of Error Message Containing Sensitive Information
Abstraction: Base · Status: Draft
The product generates an error message that includes sensitive information about its environment, users, or associated data.
833 vulnerabilities reference this CWE, most recent first.
GHSA-XVP7-8VM8-XFXX
Vulnerability from github – Published: 2025-10-20 17:55 – Updated: 2026-06-08 23:28Summary
The GoCardless components in Actualbudget in are logging responses to STDOUT in a parsed format using console.logand console.debug (Which in this version of node is an alias for console.log). This is exposing sensitive information in log files including, but not limited to:
- Gocardless bearer tokens.
- Account IBAN and Bank Account numbers.
- PII of the account holder.
- Transaction details (Payee bank information, Recipient account numbers, Transaction IDs)...
Details
Whenever GoCardless responds to a request, the payload is printed to the debug log: https://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/banks/integration-bank.js#L25-L27
This in turn logs the following information to Docker (all values removed here. These fields are possibly dependent on what is returned by each institution so may differ):
{
"account": {
"resourceId": "",
"iban": "",
"bban": "",
"currency": "",
"name": "<full legal name in the bank>",
"product": "",
"status": "",
"bic": "",
"usage": "",
"id": "",
"created": "",
"last_accessed": "",
"institution_id": "",
"owner_name": "",
"institution": {
"id": "",
"name": "",
"bic": "",
"transaction_total_days": "",
"countries": [
""
],
"logo": "",
"max_access_valid_for_days": "",
"supported_features": [
"",
"",
""
],
"identification_codes": []
}
}
}
https://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/banks/integration-bank.js#L83-L85
This is the first of the 10 transactions:
{
"top10Transactions": [{
"transactionId": "",
"entryReference": "",
"bookingDate": "",
"valueDate": "",
"transactionAmount": {
"amount": "",
"currency": ""
},
"creditorName": "",
"creditorAccount": {
"bban": ""
},
"debtorName": "",
"debtorAccount": {
"bban": ""
},
"remittanceInformationUnstructured": "",
"remittanceInformationStructuredArray": [
{"reference": "", "referenceType": ""}
],
"additionalInformation": "",
"proprietaryBankTransactionCode": "",
"debtorAgent": "",
"internalTransactionId": "",
"payeeName": "",
"date": ""
}]
}
Additionally, in the error handling for GoCardless, there is a catch all for unclassified errors that prints the entire stack trace to the console.
https://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/app-gocardless.js#L263-L264
Our bank was offline today for maintenance which threw a 503 error from Gocardless. The entire response payload was dumped to console, which includes the Bearer tokens for accessing GoCardless:
Something went wrong ServiceError: Institution service unavailable
at handleGoCardlessError (file:///app/src/app-gocardless/services/gocardless-service.js:59:13)
at Object.getTransactions (file:///app/src/app-gocardless/services/gocardless-service.js:530:7)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.getNormalizedTransactions (file:///app/src/app-gocardless/services/gocardless-service.js:267:26)
at async file:///app/src/app-gocardless/app-gocardless.js:186:13 {
details: h [AxiosError]: Request failed with status code 503
at te (file:///app/node_modules/nordigen-node/dist/index.esm.js:13:914)
at IncomingMessage.<anonymous> (file:///app/node_modules/nordigen-node/dist/index.esm.js:17:16315)
at IncomingMessage.emit (node:events:529:35)
at endReadableNT (node:internal/streams/readable:1400:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
code: 'ERR_BAD_RESPONSE',
config: {
transitional: {
silentJSONParsing: true,
forcedJSONParsing: true,
clarifyTimeoutError: false
},
adapter: [ 'xhr', 'http' ],
transformRequest: [ [Function (anonymous)] ],
transformResponse: [ [Function (anonymous)] ],
timeout: 0,
xsrfCookieName: 'XSRF-TOKEN',
xsrfHeaderName: 'X-XSRF-TOKEN',
maxContentLength: -1,
maxBodyLength: -1,
env: {
FormData: [Function: _] {
LINE_BREAK: '\r\n',
DEFAULT_CONTENT_TYPE: 'application/octet-stream'
},
Blob: [class Blob]
},
validateStatus: [Function: validateStatus],
headers: T [AxiosHeaders] {
Accept: 'application/json',
'Content-Type': 'application/json',
'User-Agent': 'Nordigen-Node-v2',
'Authorization': 'Bearer eyJ0eXAi... (the full token is in the response)',
'Accept-Encoding': 'gzip, compress, deflate, br'
},
method: 'get',
url: URL {
href: 'https://bankaccountdata.gocardless.com/api/v2/accounts/<Account id Was Here>?date_from=2024-12-22',
origin: 'https://bankaccountdata.gocardless.com',
protocol: 'https:',
username: '',
password: '',
host: 'bankaccountdata.gocardless.com',
hostname: 'bankaccountdata.gocardless.com',
port: '',
pathname: '/api/v2/accounts/<Account id Was Here>/transactions',
search: '?date_from=2024-12-22',
searchParams: URLSearchParams { 'date_from' => '2024-12-22' },
hash: ''
},
data: undefined
},
And quite a few pages more.
PoC
- Setup an Actualbudget server inside of Docker. In this instance I was using the Docker Compose script posted in the repository: https://github.com/actualbudget/actual/blob/master/packages/sync-server/docker-compose.yml
- Link a gocardless account to Actualbudget and sync a bank account
- Observe in the container using
docker logs actual-actual_server-1 -fthat sensitive details are logged to the console and ingested by docker.
Impact
Information disclosure. The services are available both on-premises and in environments that are not under the control of the end user, such as third-party providers who offer this application as a managed solution.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 25.10.0"
},
"package": {
"ecosystem": "npm",
"name": "@actual-app/sync-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "25.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-209",
"CWE-215",
"CWE-219"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-20T17:55:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe GoCardless components in Actualbudget in are logging responses to STDOUT in a parsed format using `console.log`and `console.debug` (Which in this version of node is an alias for `console.log`). This is exposing sensitive information in log files including, but not limited to:\n\n- Gocardless bearer tokens.\n- Account IBAN and Bank Account numbers.\n- PII of the account holder.\n- Transaction details (Payee bank information, Recipient account numbers, Transaction IDs)...\n\n### Details\n\nWhenever GoCardless responds to a request, the payload is printed to the debug log: \nhttps://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/banks/integration-bank.js#L25-L27\n\nThis in turn logs the following information to Docker (all values removed here. These fields are possibly dependent on what is returned by each institution so may differ):\n\n```json\n{\n \"account\": {\n \"resourceId\": \"\",\n \"iban\": \"\",\n \"bban\": \"\",\n \"currency\": \"\",\n \"name\": \"\u003cfull legal name in the bank\u003e\",\n \"product\": \"\",\n \"status\": \"\",\n \"bic\": \"\",\n \"usage\": \"\",\n \"id\": \"\",\n \"created\": \"\",\n \"last_accessed\": \"\",\n \"institution_id\": \"\",\n \"owner_name\": \"\",\n \"institution\": {\n \"id\": \"\",\n \"name\": \"\",\n \"bic\": \"\",\n \"transaction_total_days\": \"\",\n \"countries\": [\n \"\"\n ],\n \"logo\": \"\",\n \"max_access_valid_for_days\": \"\",\n \"supported_features\": [\n \"\",\n \"\",\n \"\"\n ],\n \"identification_codes\": []\n }\n }\n}\n```\n\nhttps://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/banks/integration-bank.js#L83-L85\n\nThis is the first of the 10 transactions:\n```json\n{\n \"top10Transactions\": [{\n \"transactionId\": \"\",\n \"entryReference\": \"\",\n \"bookingDate\": \"\",\n \"valueDate\": \"\",\n \"transactionAmount\": {\n \"amount\": \"\",\n \"currency\": \"\"\n },\n \"creditorName\": \"\",\n \"creditorAccount\": {\n \"bban\": \"\"\n },\n \"debtorName\": \"\",\n \"debtorAccount\": {\n \"bban\": \"\"\n },\n \"remittanceInformationUnstructured\": \"\",\n \"remittanceInformationStructuredArray\": [\n {\"reference\": \"\", \"referenceType\": \"\"}\n ],\n \"additionalInformation\": \"\",\n \"proprietaryBankTransactionCode\": \"\",\n \"debtorAgent\": \"\",\n \"internalTransactionId\": \"\",\n \"payeeName\": \"\",\n \"date\": \"\"\n }]\n}\n```\n\nAdditionally, in the error handling for GoCardless, there is a catch all for unclassified errors that prints the entire stack trace to the console.\n\nhttps://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/app-gocardless.js#L263-L264\n\nOur bank was offline today for maintenance which threw a 503 error from Gocardless. The entire response payload was dumped to console, which includes the Bearer tokens for accessing GoCardless:\n\n```java\nSomething went wrong ServiceError: Institution service unavailable\n at handleGoCardlessError (file:///app/src/app-gocardless/services/gocardless-service.js:59:13)\n at Object.getTransactions (file:///app/src/app-gocardless/services/gocardless-service.js:530:7)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async Object.getNormalizedTransactions (file:///app/src/app-gocardless/services/gocardless-service.js:267:26)\n at async file:///app/src/app-gocardless/app-gocardless.js:186:13 {\n details: h [AxiosError]: Request failed with status code 503\n at te (file:///app/node_modules/nordigen-node/dist/index.esm.js:13:914)\n at IncomingMessage.\u003canonymous\u003e (file:///app/node_modules/nordigen-node/dist/index.esm.js:17:16315)\n at IncomingMessage.emit (node:events:529:35)\n at endReadableNT (node:internal/streams/readable:1400:12)\n at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {\n code: \u0027ERR_BAD_RESPONSE\u0027,\n config: {\n transitional: {\n silentJSONParsing: true,\n forcedJSONParsing: true,\n clarifyTimeoutError: false\n },\n adapter: [ \u0027xhr\u0027, \u0027http\u0027 ],\n transformRequest: [ [Function (anonymous)] ],\n transformResponse: [ [Function (anonymous)] ],\n timeout: 0,\n xsrfCookieName: \u0027XSRF-TOKEN\u0027,\n xsrfHeaderName: \u0027X-XSRF-TOKEN\u0027,\n maxContentLength: -1,\n maxBodyLength: -1,\n env: {\n FormData: [Function: _] {\n LINE_BREAK: \u0027\\r\\n\u0027,\n DEFAULT_CONTENT_TYPE: \u0027application/octet-stream\u0027\n },\n Blob: [class Blob]\n },\n validateStatus: [Function: validateStatus],\n headers: T [AxiosHeaders] {\n Accept: \u0027application/json\u0027,\n \u0027Content-Type\u0027: \u0027application/json\u0027,\n \u0027User-Agent\u0027: \u0027Nordigen-Node-v2\u0027,\n \u0027Authorization\u0027: \u0027Bearer eyJ0eXAi... (the full token is in the response)\u0027,\n \u0027Accept-Encoding\u0027: \u0027gzip, compress, deflate, br\u0027\n },\n method: \u0027get\u0027,\n url: URL {\n href: \u0027https://bankaccountdata.gocardless.com/api/v2/accounts/\u003cAccount id Was Here\u003e?date_from=2024-12-22\u0027,\n origin: \u0027https://bankaccountdata.gocardless.com\u0027,\n protocol: \u0027https:\u0027,\n username: \u0027\u0027,\n password: \u0027\u0027,\n host: \u0027bankaccountdata.gocardless.com\u0027,\n hostname: \u0027bankaccountdata.gocardless.com\u0027,\n port: \u0027\u0027,\n pathname: \u0027/api/v2/accounts/\u003cAccount id Was Here\u003e/transactions\u0027,\n search: \u0027?date_from=2024-12-22\u0027,\n searchParams: URLSearchParams { \u0027date_from\u0027 =\u003e \u00272024-12-22\u0027 },\n hash: \u0027\u0027\n },\n data: undefined\n },\n```\nAnd quite a few pages more.\n\n### PoC\n- Setup an Actualbudget server inside of Docker. In this instance I was using the Docker Compose script posted in the repository: https://github.com/actualbudget/actual/blob/master/packages/sync-server/docker-compose.yml\n- Link a gocardless account to Actualbudget and sync a bank account\n- Observe in the container using `docker logs actual-actual_server-1 -f` that sensitive details are logged to the console and ingested by docker. \n\n### Impact\nInformation disclosure. The services are available both on-premises and in environments that are not under the control of the end user, such as third-party providers who offer this application as a managed solution.",
"id": "GHSA-xvp7-8vm8-xfxx",
"modified": "2026-06-08T23:28:41Z",
"published": "2025-10-20T17:55:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/actualbudget/actual/security/advisories/GHSA-xvp7-8vm8-xfxx"
},
{
"type": "WEB",
"url": "https://github.com/actualbudget/actual/commit/97482a082d502887ef22514b93e35e4c67f4f30f"
},
{
"type": "PACKAGE",
"url": "https://github.com/actualbudget/actual"
},
{
"type": "WEB",
"url": "https://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/app-gocardless.js#L263-L264"
},
{
"type": "WEB",
"url": "https://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/banks/integration-bank.js#L25-L27"
},
{
"type": "WEB",
"url": "https://github.com/actualbudget/actual/blob/36c40d90d2fe09eb1f25a6e2f77f6dd40638b267/packages/sync-server/src/app-gocardless/banks/integration-bank.js#L83-L85"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Actual Sync-server Gocardless service is logging sensitive data including bearer tokens and account numbers"
}
GHSA-XW22-WV29-3299
Vulnerability from github – Published: 2021-04-06 17:29 – Updated: 2021-04-02 17:05Impact
What kind of vulnerability is it? Who is impacted? Applications that are using node-etsy-client and reporting client error to the end user will offer api key value too
Patches
Has the problem been patched? What versions should users upgrade to?
creharmony/node-etsy-client#18 fixes this issue. This is fixed in node-etsy-client v0.3.0 and later.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Do not report or log etsy client error if you are using version <= v0.2.0
Update your version of node-etsy-client
References
Are there any links users can visit to find out more?
- https://github.com/creharmony/node-etsy-client/issues/17 : On connect error secret appears in error #17
For more information
If you have any questions or comments about this advisory: * Open an issue in github.com/creharmony/node-etsy-client/issues
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.0"
},
"package": {
"ecosystem": "npm",
"name": "node-etsy-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21421"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-209"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-02T17:05:21Z",
"nvd_published_at": "2021-04-01T22:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nApplications that are using node-etsy-client and reporting client error to the end user will offer api key value too\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\ncreharmony/node-etsy-client#18 fixes this issue. This is fixed in [node-etsy-client v0.3.0](https://github.com/creharmony/node-etsy-client/tree/v0.3.0) and later.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nDo not report or log etsy client error if you are using version \u003c= v0.2.0\n\nUpdate your version of node-etsy-client\n\n### References\n_Are there any links users can visit to find out more?_\n\n- https://github.com/creharmony/node-etsy-client/issues/17 : On connect error secret appears in error #17\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [github.com/creharmony/node-etsy-client/issues](https://github.com/creharmony/node-etsy-client/issues/)",
"id": "GHSA-xw22-wv29-3299",
"modified": "2021-04-02T17:05:21Z",
"published": "2021-04-06T17:29:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/creharmony/node-etsy-client/security/advisories/GHSA-xw22-wv29-3299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21421"
},
{
"type": "WEB",
"url": "https://github.com/creharmony/node-etsy-client/commit/b4beb8ef080366c1a87dbf9e163051a446acaa7d"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "ApiKey secret could be revelated on network issue"
}
GHSA-XXQ4-3742-3H28
Vulnerability from github – Published: 2022-02-09 00:00 – Updated: 2022-02-09 22:23microweber version 1.2.10 and prior may generate an error message containing sensitive information.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "microweber/microweber"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.2.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-0504"
],
"database_specific": {
"cwe_ids": [
"CWE-209"
],
"github_reviewed": true,
"github_reviewed_at": "2022-02-09T22:22:09Z",
"nvd_published_at": "2022-02-08T09:15:00Z",
"severity": "MODERATE"
},
"details": "microweber version 1.2.10 and prior may generate an error message containing sensitive information.",
"id": "GHSA-xxq4-3742-3h28",
"modified": "2022-02-09T22:23:35Z",
"published": "2022-02-09T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0504"
},
{
"type": "WEB",
"url": "https://github.com/microweber/microweber/commit/e607e5f745cd99d5c06a7fce16b3577fab8e1250"
},
{
"type": "PACKAGE",
"url": "https://github.com/microweber/microweber"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/285ff8a0-a273-4d62-ba01-3e4b4e18467b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Generation of Error Message Containing Sensitive Information in microweber"
}
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Mitigation
Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
Mitigation MIT-33
Strategy: Attack Surface Reduction
Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.
Mitigation MIT-40
Strategy: Compilation or Build Hardening
Debugging information should not make its way into a production release.
Mitigation MIT-40
Strategy: Environment Hardening
Debugging information should not make its way into a production release.
Mitigation
Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.
Mitigation
Create default error pages or messages that do not leak any information.
CAPEC-215: Fuzzing for application mapping
An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash.
CAPEC-463: Padding Oracle Crypto Attack
An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.
CAPEC-54: Query System for Information
An adversary, aware of an application's location (and possibly authorized to use the application), probes an application's structure and evaluates its robustness by submitting requests and examining responses. Often, this is accomplished by sending variants of expected queries in the hope that these modified queries might return information beyond what the expected set of queries would provide.
CAPEC-7: Blind SQL Injection
Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the adversary constructs input strings that probe the target through simple Boolean SQL expressions. The adversary can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the adversary determines how and where the target is vulnerable to SQL Injection.