Common Weakness Enumeration

CWE-215

Allowed

Insertion of Sensitive Information Into Debugging Code

Abstraction: Base · Status: Draft

The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.

35 vulnerabilities reference this CWE, most recent first.

GHSA-RJ6P-94V3-4CCP

Vulnerability from github – Published: 2024-08-13 21:31 – Updated: 2024-08-13 21:31
VLAI
Details

An information disclosure vulnerability in Ivanti ITSM on-prem and Neurons for ITSM versions 2023.4 and earlier allows an unauthenticated attacker to obtain the OIDC client secret via debug information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T19:15:16Z",
    "severity": "CRITICAL"
  },
  "details": "An information disclosure vulnerability in Ivanti ITSM on-prem and Neurons for ITSM versions 2023.4 and earlier allows an unauthenticated attacker to obtain the OIDC client secret via debug information.",
  "id": "GHSA-rj6p-94v3-4ccp",
  "modified": "2024-08-13T21:31:55Z",
  "published": "2024-08-13T21:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7569"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Neurons-for-ITSM-CVE-2024-7569-CVE-2024-7570"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9QF-M6G5-9C72

Vulnerability from github – Published: 2025-03-02 18:30 – Updated: 2025-03-02 18:30
VLAI
Details

IBM Cognos Analytics Mobile 1.1 for Android could allow a user with physical access to the device, to obtain sensitive information from debugging code log messages.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-02T16:15:35Z",
    "severity": "LOW"
  },
  "details": "IBM Cognos Analytics Mobile 1.1 for Android could allow a user with physical access to the device, to obtain sensitive information from debugging code log messages.",
  "id": "GHSA-v9qf-m6g5-9c72",
  "modified": "2025-03-02T18:30:53Z",
  "published": "2025-03-02T18:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0895"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7184430"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQF5-2XX6-9WFM

Vulnerability from github – Published: 2025-01-24 18:44 – Updated: 2025-03-31 21:55
VLAI
Summary
GitHub PAT written to debug artifacts
Details

Impact summary

In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment.

For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid GITHUB_TOKEN for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The GITHUB_TOKEN is valid until the job completes or 24 hours has elapsed, whichever comes first.

Environment variables are exposed only from workflow runs that satisfy all of the following conditions: - Code scanning workflow configured to scan the Java/Kotlin languages. - Running in a repository containing Kotlin source code. - Running with debug artifacts enabled. - Using CodeQL Action versions <= 3.28.2, and CodeQL CLI versions >= 2.9.2 (May 2022) and <= 2.20.2. - The workflow run fails before the CodeQL database is finalized within the github/codeql-action/analyze step. - Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. (Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo.)

The GITHUB_TOKEN exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above: - Using CodeQL Action versions >= 3.26.11 (October 2024) and <= 3.28.2, or >= 2.26.11 and < 3. - Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server).

In rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory GHSA-gqh3-9prg-j95m for more details.

Impact details

In CodeQL CLI versions >= 2.9.2 and <= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. This is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories. On Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned.

The intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode.

Therefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the GITHUB_TOKEN and any user-configured secrets made available via environment variables.

The impact of the GITHUB_TOKEN leaked in this environment is limited: - For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions >= 3.26.11 and <= 3.28.2, or >= 2.26.11 and < 3, which in turn use the actions/artifacts v4 library, the debug artifact is uploaded before the workflow job completes. During this time the GITHUB_TOKEN is still valid, providing an opportunity for attackers to gain access to the repository. - For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked GITHUB_TOKEN has been revoked and cannot be used to access the repository.

Mitigations

Update to CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later.

Patches

This vulnerability has been fixed in CodeQL Action version 3.28.3, which no longer uploads database artifacts in debug mode. This vulnerability will be fixed in CodeQL CLI version 2.20.3, in which database creation for all languages no longer logs the complete environment by default.

References

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.28.2"
      },
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "github/codeql-action"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.26.11"
            },
            {
              "fixed": "3.28.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.0.0"
      },
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "github/codeql-action"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.26.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-24T18:44:55Z",
    "nvd_published_at": "2025-01-24T18:15:32Z",
    "severity": "HIGH"
  },
  "details": "### Impact summary\n\nIn some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment.\n\nFor some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first.\n\nEnvironment variables are exposed only from workflow runs that satisfy all of the following conditions:\n- Code scanning workflow configured to scan the Java/Kotlin languages.\n- Running in a repository containing Kotlin source code.\n- Running with [debug artifacts enabled](https://docs.github.com/en/code-security/code-scanning/troubleshooting-code-scanning/logs-not-detailed-enough).\n- Using CodeQL Action versions \u003c= 3.28.2, and CodeQL CLI versions \u003e= 2.9.2 (May 2022) and \u003c= 2.20.2.\n- The workflow run fails before the CodeQL database is finalized within the `github/codeql-action/analyze` step.\n- Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. (Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo.)\n\nThe `GITHUB_TOKEN` exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above:\n- Using CodeQL Action versions \u003e= 3.26.11 (October 2024) and \u003c= 3.28.2, or \u003e= 2.26.11 and \u003c 3.\n- Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server).\n\nIn rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory [GHSA-gqh3-9prg-j95m](https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gqh3-9prg-j95m) for more details.\n\n\n### Impact details\n\nIn CodeQL CLI versions \u003e= 2.9.2 and \u003c= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. \nThis is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories. \nOn Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned.\n\nThe intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode.\n\nTherefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the `GITHUB_TOKEN` and any user-configured secrets made available via environment variables.\n\nThe impact of the `GITHUB_TOKEN` leaked in this environment is limited:\n- For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions \u003e= 3.26.11 and \u003c= 3.28.2, or \u003e= 2.26.11 and \u003c 3, which in turn use the `actions/artifacts v4` library, the debug artifact is uploaded before the workflow job completes. During this time the `GITHUB_TOKEN` is still valid, providing an opportunity for attackers to gain access to the repository.\n- For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked `GITHUB_TOKEN` has been revoked and cannot be used to access the repository.\n\n### Mitigations\n\nUpdate to CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later.\n\n### Patches\n\nThis vulnerability has been fixed in CodeQL Action version 3.28.3, which no longer uploads database artifacts in debug mode.\nThis vulnerability will be fixed in CodeQL CLI version 2.20.3, in which database creation for all languages no longer logs the complete environment by default.\n\n### References\n\n- [Pull request that bundled CodeQL CLI 2.9.2 with Kotlin extractor environment variable logging ](https://github.com/github/codeql-action/pull/1074)\n- [Pull request that introduced the `actions/artifacts v4` library, allowing for `GITHUB_TOKEN` exposure in the CodeQL Action debug artifacts before the token was revoked](https://github.com/github/codeql-action/pull/2482)\n- [Related security advisory for the CodeQL CLI](https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gqh3-9prg-j95m)",
  "id": "GHSA-vqf5-2xx6-9wfm",
  "modified": "2025-03-31T21:55:42Z",
  "published": "2025-01-24T18:44:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/security/advisories/GHSA-vqf5-2xx6-9wfm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gqh3-9prg-j95m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24362"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/pull/1074"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/pull/2482"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/commit/519de26711ecad48bde264c51e414658a82ef3fa"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/code-security/code-scanning/troubleshooting-code-scanning/logs-not-detailed-enough"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/github/codeql-action"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=43527044"
    },
    {
      "type": "WEB",
      "url": "https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GitHub PAT written to debug artifacts"
}

GHSA-X6G4-F6Q3-FQVV

Vulnerability from github – Published: 2026-03-24 20:44 – Updated: 2026-03-27 20:57
VLAI
Summary
NATS credentials are exposed in monitoring port via command-line argv
Details

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an optional monitoring port, which provides access to sensitive data. The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.

Problem Description

If a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.

The /debug/vars end-point contains an unredacted copy of argv.

Patches

Fixed in nats-server 2.12.6 & 2.11.15

Workarounds

The NATS Maintainers are bemused at the concept of someone deploying a real configuration using --pass to avoid a config file, but also enabling monitoring.

Configure credentials inside a configuration file instead of via argv.

Do not enable the monitoring port if using secrets in argv.

Best practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0-RC.1"
            },
            {
              "fixed": "2.12.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T20:44:00Z",
    "nvd_published_at": "2026-03-25T20:16:33Z",
    "severity": "HIGH"
  },
  "details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nThe nats-server provides an optional monitoring port, which provides access to sensitive data.  The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.\n\n\n### Problem Description\n\nIf a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.\n\nThe `/debug/vars` end-point contains an unredacted copy of argv.\n\n### Patches\n\nFixed in nats-server 2.12.6 \u0026 2.11.15\n\n### Workarounds\n\nThe NATS Maintainers are bemused at the concept of someone deploying a real configuration using `--pass` to avoid a config file, but also enabling monitoring.\n\nConfigure credentials inside a configuration file instead of via argv.\n\nDo not enable the monitoring port if using secrets in argv.\n\nBest practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.",
  "id": "GHSA-x6g4-f6q3-fqvv",
  "modified": "2026-03-27T20:57:01Z",
  "published": "2026-03-24T20:44:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-x6g4-f6q3-fqvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33247"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/secnote-2026-14.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats-server"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NATS credentials are exposed in monitoring port via command-line argv"
}

GHSA-XVP7-8VM8-XFXX

Vulnerability from github – Published: 2025-10-20 17:55 – Updated: 2026-06-08 23:28
VLAI
Summary
Actual Sync-server Gocardless service is logging sensitive data including bearer tokens and account numbers
Details

Summary

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 -f that 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.

Show details on source website

{
  "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"
}

Mitigation
Implementation

Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software.

Mitigation MIT-46
Architecture and Design

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.

No CAPEC attack patterns related to this CWE.