CWE-532
AllowedInsertion of Sensitive Information into Log File
Abstraction: Base · Status: Incomplete
The product writes sensitive information to a log file.
1961 vulnerabilities reference this CWE, most recent first.
GHSA-HC4Q-M2PQ-FRR6
Vulnerability from github – Published: 2026-07-30 09:31 – Updated: 2026-07-30 09:31The credentials for the local user "user-app" may be exposed in log files, potentially enabling a low-privileged local attacker with access to the logs to authenticate via SSH as the limited user "user-app". Charging could be interrupted.
{
"affected": [],
"aliases": [
"CVE-2026-44105"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T07:16:58Z",
"severity": "MODERATE"
},
"details": "The credentials for the local user \"user-app\" may be exposed in log files, potentially enabling a low-privileged local attacker with access to the logs to authenticate via SSH as the limited user \"user-app\". Charging could be interrupted.",
"id": "GHSA-hc4q-m2pq-frr6",
"modified": "2026-07-30T09:31:18Z",
"published": "2026-07-30T09:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44105"
},
{
"type": "WEB",
"url": "https://www.certvde.com/en/advisories/VDE-2026-008"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-HCMV-JMQH-FJGM
Vulnerability from github – Published: 2024-07-22 17:40 – Updated: 2024-07-22 17:40Summary
The issue here is that we pass the secret content as one of the args via CLI. This issue may affect any of our charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing subprocess.CalledProcessError.
There are two points that may log this command, in different files:
First, if there is an error during a secret handling, there will be a subprocess.CalledProcessError, which will contain the CLI comand + all its args. This is going to be logged in any logging level. This exception, if not caught by the charm, will bubble up to the /var/log/juju/ logs and syslog journal. Now, on Ubuntu 22.04, these logs are protected with:
$ juju ssh -m controller 0 -- ls -la /var/log/juju/
total 224
drwxr-xr-x 2 syslog adm 4096 Jul 14 10:59 .
drwxrwxr-x 9 root syslog 4096 Jul 14 10:58 ..
-rw-r----- 1 syslog adm 20124 Jul 14 11:10 audit.log
-rw-r----- 1 syslog adm 110432 Jul 14 11:10 logsink.log
-rw-r----- 1 syslog adm 80783 Jul 14 11:06 machine-0.log
-rw-r----- 1 syslog adm 766 Jul 14 11:10 machine-lock.log
-rw-r--r-- 1 root root 0 Jul 14 10:59 slow-query.log
-rw-r----- 1 syslog adm 3732 Jul 14 11:10 unit-controller-0.log
Second, certain audit setups may log terminal commands, which would result in this command being logged with its secrets. It is unknown if this is done on ubuntu security benchmarks, such as CIS hardening.
Keep in mind these logs may be copied or even backed up. Which exposes it to more services in the user's environment (e.g. CI runs in GH - although these are dummy password generated per test only).
Passing secrets straight via CLI is not advised. Here are some ways out:
1) Redacting: which commands and which args represent secrets are known, so they can be redacted. It would also mean capturing a subprocess.CalledProcessError, redacting its content and reissuing the same type of exception; this will not cover the case auditd is set to log CLI commands, if that is a risk
2) Temp files: secret-add, for example, can use a secret file instead, as can be seen here. However, if ops uses a file, ops will need to be sure to correctly remove it later
3) stdin: not sure it is accepted by secret-* commands, but generally, secrets are not shown on CLI whilst typing them; auditd may not capture that stdin
Severity Rationale
This is a CWE-532. Potentially, these secrets can lead to privilege escalation but Ubuntu default is to have logs only accessible to adm group users.
Marking this issue as "Moderate", as this report is not presenting a clear way on how to get access to the logs themselves: either getting local access to an adm group user (e.g. ubuntu) or recovering logs stored on a 3rd party service.
Details
2024-07-12T14:27:58.0175389Z unit-opensearch-3: 14:27:53 ERROR unit.opensearch/3.juju-log certificates:11: Uncaught exception while in charm code:
2024-07-12T14:27:58.0175524Z Traceback (most recent call last):
2024-07-12T14:27:58.0175957Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 3180, in _run
2024-07-12T14:27:58.0176165Z result = subprocess.run(args, **kwargs) # type: ignore
2024-07-12T14:27:58.0176381Z File "/usr/lib/python3.10/subprocess.py", line 526, in run
2024-07-12T14:27:58.0176561Z raise CalledProcessError(retcode, process.args,
2024-07-12T14:27:58.0177749Z subprocess.CalledProcessError: Command '('/var/lib/juju/tools/unit-opensearch-3/secret-add', '--label', 'opensearch:app:app-admin', '--owner', 'application', 'keystore-password-ca=aUE...')' returned non-zero exit status 1.
2024-07-12T14:27:58.0177765Z
2024-07-12T14:27:58.0178023Z The above exception was the direct cause of the following exception:
2024-07-12T14:27:58.0178038Z
2024-07-12T14:27:58.0178168Z Traceback (most recent call last):
2024-07-12T14:27:58.0178588Z File "/var/lib/juju/agents/unit-opensearch-3/charm/./src/charm.py", line 213, in <module>
2024-07-12T14:27:58.0178724Z main(OpenSearchOperatorCharm)
2024-07-12T14:27:58.0179129Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py", line 548, in main
2024-07-12T14:27:58.0179237Z manager.run()
2024-07-12T14:27:58.0179640Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py", line 527, in run
2024-07-12T14:27:58.0179745Z self._emit()
2024-07-12T14:27:58.0180150Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py", line 516, in _emit
2024-07-12T14:27:58.0180359Z _emit_charm_event(self.charm, self.dispatcher.event_name)
2024-07-12T14:27:58.0180840Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py", line 147, in _emit_charm_event
2024-07-12T14:27:58.0180974Z event_to_emit.emit(*args, **kwargs)
2024-07-12T14:27:58.0181537Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py", line 348, in emit
2024-07-12T14:27:58.0181656Z framework._emit(event)
2024-07-12T14:27:58.0182091Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py", line 860, in _emit
2024-07-12T14:27:58.0182211Z self._reemit(event_path)
2024-07-12T14:27:58.0182659Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py", line 950, in _reemit
2024-07-12T14:27:58.0182770Z custom_handler(event)
2024-07-12T14:27:58.0183492Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/tls_certificates_interface/v3/tls_certificates.py", line 1811, in _on_relation_changed
2024-07-12T14:27:58.0183743Z self.on.certificate_available.emit(
2024-07-12T14:27:58.0184173Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py", line 348, in emit
2024-07-12T14:27:58.0184291Z framework._emit(event)
2024-07-12T14:27:58.0184717Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py", line 860, in _emit
2024-07-12T14:27:58.0184887Z self._reemit(event_path)
2024-07-12T14:27:58.0186171Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py", line 950, in _reemit
2024-07-12T14:27:58.0186306Z custom_handler(event)
2024-07-12T14:27:58.0187043Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_tls.py", line 209, in _on_certificate_available
2024-07-12T14:27:58.0187320Z self.store_new_ca(self.charm.secrets.get_object(scope, cert_type.val))
2024-07-12T14:27:58.0187942Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_tls.py", line 444, in store_new_ca
2024-07-12T14:27:58.0188242Z self._create_keystore_pwd_if_not_exists(Scope.APP, CertType.APP_ADMIN, "ca")
2024-07-12T14:27:58.0188981Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_tls.py", line 432, in _create_keystore_pwd_if_not_exists
2024-07-12T14:27:58.0189119Z self.charm.secrets.put_object(
2024-07-12T14:27:58.0189738Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_secrets.py", line 359, in put_object
2024-07-12T14:27:58.0189944Z self._add_or_update_juju_secret(scope, key, value, merge)
2024-07-12T14:27:58.0190652Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_secrets.py", line 272, in _add_or_update_juju_secret
2024-07-12T14:27:58.0190815Z return self._add_juju_secret(scope, key, value)
2024-07-12T14:27:58.0191462Z File "/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_secrets.py", line 228, in _add_juju_secret
2024-07-12T14:27:58.0191660Z secret = scope_obj.add_secret(safe_value, label=label)
2024-07-12T14:27:58.0192110Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 477, in add_secret
2024-07-12T14:27:58.0192241Z id = self._backend.secret_add(
2024-07-12T14:27:58.0192686Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 3624, in secret_add
2024-07-12T14:27:58.0192948Z result = self._run('secret-add', *args, return_output=True)
2024-07-12T14:27:58.0193356Z File "/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py", line 3182, in _run
2024-07-12T14:27:58.0193489Z raise ModelError(e.stderr) from e
2024-07-12T14:27:58.0193685Z ops.model.ModelError: ERROR this unit is not the leader
2024-07-12T14:27:58.0193692Z
From CI: https://github.com/canonical/opensearch-operator/actions/runs/9908987369/job/27376377521?pr=364
PoC
1) Deploy anything with juju 2) Run a dummy secret-add call that will fail 3) See the uncaught subprocess error
Impact
Juju secrets are generally composed of private keys, passwords, etc; generally valuable credentials that, if leaked, will likely allow an attacker to get privileged access to its target or other targets in the environment.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ops"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-41129"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-22T17:40:40Z",
"nvd_published_at": "2024-07-22T15:15:03Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe issue here is that we pass the secret content as one of the args via CLI. This issue may affect any of our charms that are using: Juju (\u003e=3.0), Juju secrets and not correctly capturing and processing `subprocess.CalledProcessError`.\n\nThere are two points that may log this command, in different files:\n\nFirst, if there is an error during a secret handling, there will be a `subprocess.CalledProcessError`, which will contain the CLI comand + all its args. This is going to be logged in any logging level. This exception, if not caught by the charm, will bubble up to the `/var/log/juju/` logs and syslog journal. Now, on Ubuntu 22.04, these logs are protected with:\n```\n$ juju ssh -m controller 0 -- ls -la /var/log/juju/\ntotal 224\ndrwxr-xr-x 2 syslog adm 4096 Jul 14 10:59 .\ndrwxrwxr-x 9 root syslog 4096 Jul 14 10:58 ..\n-rw-r----- 1 syslog adm 20124 Jul 14 11:10 audit.log\n-rw-r----- 1 syslog adm 110432 Jul 14 11:10 logsink.log\n-rw-r----- 1 syslog adm 80783 Jul 14 11:06 machine-0.log\n-rw-r----- 1 syslog adm 766 Jul 14 11:10 machine-lock.log\n-rw-r--r-- 1 root root 0 Jul 14 10:59 slow-query.log\n-rw-r----- 1 syslog adm 3732 Jul 14 11:10 unit-controller-0.log\n```\n\nSecond, certain audit setups may log terminal commands, which would result in this command being logged with its secrets. It is unknown if this is done on ubuntu security benchmarks, such as CIS hardening.\n\nKeep in mind these logs may be copied or even backed up. Which exposes it to more services in the user\u0027s environment (e.g. CI runs in GH - although these are dummy password generated per test only).\n\nPassing secrets straight via CLI is not advised. Here are some ways out:\n1) Redacting: which commands and which args represent secrets are known, so they can be redacted. It would also mean capturing a `subprocess.CalledProcessError`, redacting its content and reissuing the same type of exception; this will not cover the case `auditd` is set to log CLI commands, if that is a risk\n2) Temp files: secret-add, for example, can use a secret file instead, [as can be seen here](https://github.com/juju/juju/blob/20b7d944acc985ce91419728529d5fb2abd14d68/cmd/juju/secrets/add.go#L62). However, if ops uses a file, ops will need to be sure to correctly remove it later\n3) stdin: not sure it is accepted by secret-* commands, but generally, secrets are not shown on CLI whilst typing them; auditd may not capture that stdin\n\n### Severity Rationale\n\nThis is a [CWE-532](https://cwe.mitre.org/data/definitions/532.html). Potentially, these secrets can lead to privilege escalation but Ubuntu default is to have logs only accessible to `adm` group users.\n\nMarking this issue as \"Moderate\", as this report is not presenting a clear way on how to get access to the logs themselves: either getting local access to an `adm` group user (e.g. ubuntu) or recovering logs stored on a 3rd party service.\n\n### Details\n```\n2024-07-12T14:27:58.0175389Z unit-opensearch-3: 14:27:53 ERROR unit.opensearch/3.juju-log certificates:11: Uncaught exception while in charm code:\n2024-07-12T14:27:58.0175524Z Traceback (most recent call last):\n2024-07-12T14:27:58.0175957Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py\", line 3180, in _run\n2024-07-12T14:27:58.0176165Z result = subprocess.run(args, **kwargs) # type: ignore\n2024-07-12T14:27:58.0176381Z File \"/usr/lib/python3.10/subprocess.py\", line 526, in run\n2024-07-12T14:27:58.0176561Z raise CalledProcessError(retcode, process.args,\n2024-07-12T14:27:58.0177749Z subprocess.CalledProcessError: Command \u0027(\u0027/var/lib/juju/tools/unit-opensearch-3/secret-add\u0027, \u0027--label\u0027, \u0027opensearch:app:app-admin\u0027, \u0027--owner\u0027, \u0027application\u0027, \u0027keystore-password-ca=aUE...\u0027)\u0027 returned non-zero exit status 1.\n2024-07-12T14:27:58.0177765Z\n2024-07-12T14:27:58.0178023Z The above exception was the direct cause of the following exception:\n2024-07-12T14:27:58.0178038Z\n2024-07-12T14:27:58.0178168Z Traceback (most recent call last):\n2024-07-12T14:27:58.0178588Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/./src/charm.py\", line 213, in \u003cmodule\u003e\n2024-07-12T14:27:58.0178724Z main(OpenSearchOperatorCharm)\n2024-07-12T14:27:58.0179129Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py\", line 548, in main\n2024-07-12T14:27:58.0179237Z manager.run()\n2024-07-12T14:27:58.0179640Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py\", line 527, in run\n2024-07-12T14:27:58.0179745Z self._emit()\n2024-07-12T14:27:58.0180150Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py\", line 516, in _emit\n2024-07-12T14:27:58.0180359Z _emit_charm_event(self.charm, self.dispatcher.event_name)\n2024-07-12T14:27:58.0180840Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/main.py\", line 147, in _emit_charm_event\n2024-07-12T14:27:58.0180974Z event_to_emit.emit(*args, **kwargs)\n2024-07-12T14:27:58.0181537Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py\", line 348, in emit\n2024-07-12T14:27:58.0181656Z framework._emit(event)\n2024-07-12T14:27:58.0182091Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py\", line 860, in _emit\n2024-07-12T14:27:58.0182211Z self._reemit(event_path)\n2024-07-12T14:27:58.0182659Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py\", line 950, in _reemit\n2024-07-12T14:27:58.0182770Z custom_handler(event)\n2024-07-12T14:27:58.0183492Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/tls_certificates_interface/v3/tls_certificates.py\", line 1811, in _on_relation_changed\n2024-07-12T14:27:58.0183743Z self.on.certificate_available.emit(\n2024-07-12T14:27:58.0184173Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py\", line 348, in emit\n2024-07-12T14:27:58.0184291Z framework._emit(event)\n2024-07-12T14:27:58.0184717Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py\", line 860, in _emit\n2024-07-12T14:27:58.0184887Z self._reemit(event_path)\n2024-07-12T14:27:58.0186171Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/framework.py\", line 950, in _reemit\n2024-07-12T14:27:58.0186306Z custom_handler(event)\n2024-07-12T14:27:58.0187043Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_tls.py\", line 209, in _on_certificate_available\n2024-07-12T14:27:58.0187320Z self.store_new_ca(self.charm.secrets.get_object(scope, cert_type.val))\n2024-07-12T14:27:58.0187942Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_tls.py\", line 444, in store_new_ca\n2024-07-12T14:27:58.0188242Z self._create_keystore_pwd_if_not_exists(Scope.APP, CertType.APP_ADMIN, \"ca\")\n2024-07-12T14:27:58.0188981Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_tls.py\", line 432, in _create_keystore_pwd_if_not_exists\n2024-07-12T14:27:58.0189119Z self.charm.secrets.put_object(\n2024-07-12T14:27:58.0189738Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_secrets.py\", line 359, in put_object\n2024-07-12T14:27:58.0189944Z self._add_or_update_juju_secret(scope, key, value, merge)\n2024-07-12T14:27:58.0190652Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_secrets.py\", line 272, in _add_or_update_juju_secret\n2024-07-12T14:27:58.0190815Z return self._add_juju_secret(scope, key, value)\n2024-07-12T14:27:58.0191462Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/lib/charms/opensearch/v0/opensearch_secrets.py\", line 228, in _add_juju_secret\n2024-07-12T14:27:58.0191660Z secret = scope_obj.add_secret(safe_value, label=label)\n2024-07-12T14:27:58.0192110Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py\", line 477, in add_secret\n2024-07-12T14:27:58.0192241Z id = self._backend.secret_add(\n2024-07-12T14:27:58.0192686Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py\", line 3624, in secret_add\n2024-07-12T14:27:58.0192948Z result = self._run(\u0027secret-add\u0027, *args, return_output=True)\n2024-07-12T14:27:58.0193356Z File \"/var/lib/juju/agents/unit-opensearch-3/charm/venv/ops/model.py\", line 3182, in _run\n2024-07-12T14:27:58.0193489Z raise ModelError(e.stderr) from e\n2024-07-12T14:27:58.0193685Z ops.model.ModelError: ERROR this unit is not the leader\n2024-07-12T14:27:58.0193692Z\n```\n\nFrom CI: https://github.com/canonical/opensearch-operator/actions/runs/9908987369/job/27376377521?pr=364\n\n### PoC\n1) Deploy anything with juju\n2) Run a dummy secret-add call that will fail\n3) See the uncaught subprocess error\n\n### Impact\nJuju secrets are generally composed of private keys, passwords, etc; generally valuable credentials that, if leaked, will likely allow an attacker to get privileged access to its target or other targets in the environment.\n",
"id": "GHSA-hcmv-jmqh-fjgm",
"modified": "2024-07-22T17:40:40Z",
"published": "2024-07-22T17:40:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/canonical/operator/security/advisories/GHSA-hcmv-jmqh-fjgm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41129"
},
{
"type": "WEB",
"url": "https://github.com/canonical/operator/commit/fea6d2072435a62170d4c01272572f1a7e916e61"
},
{
"type": "PACKAGE",
"url": "https://github.com/canonical/operator"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"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": "ops leaking secrets if `subprocess.CalledProcessError` happens with a `secret-*` CLI command"
}
GHSA-HCR5-QM3Q-XH23
Vulnerability from github – Published: 2023-02-01 15:30 – Updated: 2023-02-08 21:30Dell PowerScale OneFS 9.0.0.x - 9.4.0.x contain an insertion of sensitive information into log file vulnerability in celog. A low privileges user could potentially exploit this vulnerability, leading to information disclosure and escalation of privileges.
{
"affected": [],
"aliases": [
"CVE-2023-22575"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-01T14:15:00Z",
"severity": "HIGH"
},
"details": "Dell PowerScale OneFS 9.0.0.x - 9.4.0.x contain an insertion of sensitive information into log file vulnerability in celog. A low privileges user could potentially exploit this vulnerability, leading to information disclosure and escalation of privileges.",
"id": "GHSA-hcr5-qm3q-xh23",
"modified": "2023-02-08T21:30:19Z",
"published": "2023-02-01T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22575"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000207863/dell-powerscale-onefs-security-updates-for-multiple-security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HCR5-WV4P-H2G2
Vulnerability from github – Published: 2025-01-29 20:47 – Updated: 2025-02-05 16:28Impact
What kind of vulnerability is it? Who is impacted? If the "full-elastic-stack" example vector configuration was used for a real cluster, the previous values of kubernetes secrets would have been disclosed in the audit messages.
Patches
Has the problem been patched? What versions should users upgrade to? The example has been updated to fix this in commit 9df8886b4819409f566233adc7c3b7a43a4096ba
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading? Replace
if .request.requestKind.kind == "Secret" {
del(.request.object.data)
.request.object.data.redacted = "REDACTED"
del(.request.oldObject.data)
.request.oldObject.data.redacted = "REDACTED"
}
In the vector "audit-files-json-parser-and-redaction" step with
if .request.requestKind.kind == "Secret" {
# Redact the secret data
del(.request.object.data)
.request.object.data.redacted = "REDACTED"
del(.request.oldObject.data)
.request.oldObject.data.redacted = "REDACTED"
# Remove the previously set secret data - Not bothering to parse it as this annotation shouldn't ever be needed
del(.request.object.metadata.annotations.["kubectl.kubernetes.io/last-applied-configuration"])
del(.request.oldObject.metadata.annotations.["kubectl.kubernetes.io/last-applied-configuration"])
}
References
Are there any links users can visit to find out more?
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/RichardoC/kube-audit-rest"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20250205113217-9df8886b4819"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24884"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-29T20:47:51Z",
"nvd_published_at": "2025-01-29T21:15:21Z",
"severity": "MODERATE"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nIf the \"full-elastic-stack\" example vector configuration was used for a real cluster, the previous values of kubernetes secrets would have been disclosed in the audit messages.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\nThe example has been updated to fix this in commit 9df8886b4819409f566233adc7c3b7a43a4096ba\n\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nReplace \n```yaml\n\n if .request.requestKind.kind == \"Secret\" {\n del(.request.object.data)\n .request.object.data.redacted = \"REDACTED\"\n del(.request.oldObject.data)\n .request.oldObject.data.redacted = \"REDACTED\"\n }\n```\nIn the vector \"audit-files-json-parser-and-redaction\" step\nwith\n```yaml\n\n if .request.requestKind.kind == \"Secret\" {\n # Redact the secret data\n del(.request.object.data)\n .request.object.data.redacted = \"REDACTED\"\n del(.request.oldObject.data)\n .request.oldObject.data.redacted = \"REDACTED\"\n # Remove the previously set secret data - Not bothering to parse it as this annotation shouldn\u0027t ever be needed\n del(.request.object.metadata.annotations.[\"kubectl.kubernetes.io/last-applied-configuration\"])\n del(.request.oldObject.metadata.annotations.[\"kubectl.kubernetes.io/last-applied-configuration\"])\n }\n```\n\n\n### References\n_Are there any links users can visit to find out more?_",
"id": "GHSA-hcr5-wv4p-h2g2",
"modified": "2025-02-05T16:28:49Z",
"published": "2025-01-29T20:47:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/RichardoC/kube-audit-rest/security/advisories/GHSA-hcr5-wv4p-h2g2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24884"
},
{
"type": "WEB",
"url": "https://github.com/RichardoC/kube-audit-rest/commit/db1aa5b867256b0a7bf206544c6981ab068b73dc"
},
{
"type": "PACKAGE",
"url": "https://github.com/RichardoC/kube-audit-rest"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3431"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "kube-audit-rest\u0027s example logging configuration could disclose secret values in the audit log"
}
GHSA-HCRF-J785-XGWJ
Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2024-04-04 02:54A vulnerability in the audit logging component of Cisco Digital Network Architecture (DNA) Center could allow an authenticated, remote attacker to view sensitive information in clear text. The vulnerability is due to the storage of certain unencrypted credentials. An attacker could exploit this vulnerability by accessing the audit logs and obtaining credentials that they may not normally have access to. A successful exploit could allow the attacker to use those credentials to discover and manage network devices.
{
"affected": [],
"aliases": [
"CVE-2020-3281"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-03T18:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the audit logging component of Cisco Digital Network Architecture (DNA) Center could allow an authenticated, remote attacker to view sensitive information in clear text. The vulnerability is due to the storage of certain unencrypted credentials. An attacker could exploit this vulnerability by accessing the audit logs and obtaining credentials that they may not normally have access to. A successful exploit could allow the attacker to use those credentials to discover and manage network devices.",
"id": "GHSA-hcrf-j785-xgwj",
"modified": "2024-04-04T02:54:01Z",
"published": "2022-05-24T17:19:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3281"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dnac-audit-log-59RBdwb6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HF5V-R8XG-7R35
Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-05-24 17:47A clear text storage of sensitive information into log file vulnerability in FortiADCManager 5.3.0 and below, 5.2.1 and below and FortiADC 5.3.7 and below may allow a remote authenticated attacker to read other local users' password in log files.
{
"affected": [],
"aliases": [
"CVE-2021-24024"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-12T15:15:00Z",
"severity": "MODERATE"
},
"details": "A clear text storage of sensitive information into log file vulnerability in FortiADCManager 5.3.0 and below, 5.2.1 and below and FortiADC 5.3.7 and below may allow a remote authenticated attacker to read other local users\u0027 password in log files.",
"id": "GHSA-hf5v-r8xg-7r35",
"modified": "2022-05-24T17:47:07Z",
"published": "2022-05-24T17:47:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24024"
},
{
"type": "WEB",
"url": "https://fortiguard.com/advisory/FG-IR-19-244"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HFGF-J9PJ-WG8W
Vulnerability from github – Published: 2024-01-08 21:30 – Updated: 2026-04-28 21:33Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Jordy Meow Database Cleaner: Clean, Optimize & Repair.This issue affects Database Cleaner: Clean, Optimize & Repair: from n/a through 0.9.8.
{
"affected": [],
"aliases": [
"CVE-2023-51508"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-08T21:15:09Z",
"severity": "MODERATE"
},
"details": "Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Jordy Meow Database Cleaner: Clean, Optimize \u0026 Repair.This issue affects Database Cleaner: Clean, Optimize \u0026 Repair: from n/a through 0.9.8.",
"id": "GHSA-hfgf-j9pj-wg8w",
"modified": "2026-04-28T21:33:46Z",
"published": "2024-01-08T21:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51508"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/database-cleaner/wordpress-database-cleaner-plugin-0-9-8-sensitive-data-exposure-via-log-file-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HFRG-MCVW-8MCH
Vulnerability from github – Published: 2026-04-16 20:42 – Updated: 2026-04-24 20:36Summary
The InboxHandlingService logs the full content of every incoming inbox message at INFO level (logger.info("Received message: {}", message)). Inbox messages are wrappers around outbox message data, which can contain highly sensitive information such as personal data (PII), citizen identifiers (BSN), and case details.
Impact
This data is exposed to: - Anyone with access to application logs (stdout/log files) - Any Valtimo user with the admin role, through the logging module in the Admin UI
Affected Code
com.ritense.inbox.InboxHandlingService#handle in the inbox module.
Resolution
Fixed in 13.22.0 via commit f16a1940ba (PR #497, tracking issue gzac-issues#653). The log statement was downgraded from INFO to DEBUG and the message payload was removed from the log output.
Mitigation
For versions before 13.22.0, consider:
- Restricting access to application logs
- Adjusting the log level for com.ritense.inbox to WARN or higher in your application configuration
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.ritense.valtimo:inbox"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0.RELEASE"
},
{
"fixed": "13.22.0.RELEASE"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34164"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T20:42:55Z",
"nvd_published_at": "2026-04-16T22:16:37Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `InboxHandlingService` logs the full content of every incoming inbox message at INFO level (`logger.info(\"Received message: {}\", message)`). Inbox messages are wrappers around outbox message data, which can contain highly sensitive information such as personal data (PII), citizen identifiers (BSN), and case details.\n\n### Impact\n\nThis data is exposed to:\n- Anyone with access to application logs (stdout/log files)\n- Any Valtimo user with the admin role, through the logging module in the Admin UI\n\n### Affected Code\n\n`com.ritense.inbox.InboxHandlingService#handle` in the `inbox` module.\n\n### Resolution\n\nFixed in [13.22.0](https://github.com/valtimo-platform/valtimo/releases/tag/13.22.0) via commit [`f16a1940ba`](https://github.com/valtimo-platform/valtimo/commit/f16a1940ba7b34627c0b966f98ca78655ace9335) (PR [#497](https://github.com/valtimo-platform/valtimo/pull/497), tracking issue [gzac-issues#653](https://github.com/generiekzaakafhandelcomponent/gzac-issues/issues/653)). The log statement was downgraded from INFO to DEBUG and the message payload was removed from the log output.\n\n### Mitigation\n\nFor versions before 13.22.0, consider:\n- Restricting access to application logs\n- Adjusting the log level for `com.ritense.inbox` to WARN or higher in your application configuration",
"id": "GHSA-hfrg-mcvw-8mch",
"modified": "2026-04-24T20:36:49Z",
"published": "2026-04-16T20:42:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/valtimo-platform/valtimo/security/advisories/GHSA-hfrg-mcvw-8mch"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34164"
},
{
"type": "WEB",
"url": "https://github.com/generiekzaakafhandelcomponent/gzac-issues/issues/653"
},
{
"type": "WEB",
"url": "https://github.com/valtimo-platform/valtimo/pull/497"
},
{
"type": "WEB",
"url": "https://github.com/valtimo-platform/valtimo/commit/f16a1940ba7b34627c0b966f98ca78655ace9335"
},
{
"type": "PACKAGE",
"url": "https://github.com/valtimo-platform/valtimo"
},
{
"type": "WEB",
"url": "https://github.com/valtimo-platform/valtimo/releases/tag/13.22.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Valtimo: Sensitive data exposure through inbox message logging in InboxHandlingService"
}
GHSA-HG9M-423C-V2W6
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31API Connect V2018.1 through 2018.4.1.1 is impacted by access token leak. Authorization tokens in some URLs can result in the tokens being written to log files. IBM X-Force ID: 155626.
{
"affected": [],
"aliases": [
"CVE-2019-4008"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-07T15:29:00Z",
"severity": "CRITICAL"
},
"details": "API Connect V2018.1 through 2018.4.1.1 is impacted by access token leak. Authorization tokens in some URLs can result in the tokens being written to log files. IBM X-Force ID: 155626.",
"id": "GHSA-hg9m-423c-v2w6",
"modified": "2022-05-13T01:31:14Z",
"published": "2022-05-13T01:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4008"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/155626"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/docview.wss?uid=ibm10869772"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106961"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HGG8-FQQC-VFMW
Vulnerability from github – Published: 2026-06-17 14:04 – Updated: 2026-07-20 13:36vLLM: incomplete CVE-2026-22778 fix leaks PIL repr addresses via the Anthropic API router
Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research
Severity: CVSS 3.1 5.3 (Medium) AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Target: https://github.com/vllm-project/vllm
Summary
The fix for CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv (PRs #31987 and #32319) introduced sanitize_message and applied it at four FastAPI exception-handling sites in the OpenAI router. The sanitizer strips object-repr memory addresses (<_io.BytesIO object at 0x7a95e299e750> → <_io.BytesIO object>) before error messages reach the client, defeating the ASLR-bypass primitive that CVE-2026-22778 chained with a libopenjp2 heap overflow for RCE.
The fix is incomplete: response paths added to vLLM at or after the same time as the fix continue to echo str(exc) directly to clients without sanitize_message. The original Stage 1 primitive — sending malformed image bytes so PIL raises UnidentifiedImageError whose message contains the BytesIO object repr — reaches all of them unmodified and leaks the heap address verbatim in the response body.
All five lines below are present in main HEAD (771e1e48b, 2026-05-26).
Affected sites
Current main HEAD (771e1e48b, 2026-05-26):
| # | File | Line | Code |
|---|---|---|---|
| 1 | vllm/entrypoints/anthropic/api_router.py |
78 | message=str(e), (inside POST /v1/messages exception handler) |
| 2 | vllm/entrypoints/anthropic/api_router.py |
124 | message=str(e), (inside POST /v1/messages/count_tokens) |
| 3 | vllm/entrypoints/anthropic/serving.py |
808 | error=AnthropicError(type="internal_error", message=str(e)), (SSE streaming converter) |
| 4 | vllm/entrypoints/speech_to_text/realtime/connection.py |
75 | await self.send_error(str(e), "processing_error") (WebSocket event loop) |
| 5 | vllm/entrypoints/speech_to_text/realtime/connection.py |
265 | await self.send_error(str(e), "processing_error") (WebSocket generation loop) |
Why the global exception handler does not save these paths
api_server.py registers a catch-all app.exception_handler(Exception)(exception_handler) at line 262, and that handler calls create_error_response(exc) which DOES apply sanitize_message. However, FastAPI exception handlers fire only on unhandled exceptions that propagate out of a route function.
All affected HTTP paths catch Exception inside the route coroutine and construct the response themselves:
# vllm/entrypoints/anthropic/api_router.py:71-81 (POST /v1/messages)
try:
generator = await handler.create_messages(request, raw_request)
except Exception as e:
logger.exception("Error in create_messages: %s", e)
return JSONResponse(
status_code=HTTPStatus.INTERNAL_SERVER_ERROR.value,
content=AnthropicErrorResponse(
error=AnthropicError(
type="internal_error",
message=str(e), # <-- unsanitized
)
).model_dump(),
)
Because the exception is caught and a JSONResponse is returned in-route, every registered FastAPI exception handler — including the sanitizing global one — is bypassed. The WebSocket path bypasses it for a different reason: WebSocket frames don't traverse FastAPI's HTTP exception handler chain at all.
Reachability — the same primitive as the parent CVE
The Anthropic Messages API accepts image content parts in the request body (type: "image" with base64 source.data or type: "image_url"). Image bytes are passed to the same multimodal loader used by the OpenAI router. Malformed bytes cause PIL.Image.open to raise:
UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7a95e299e750>
The exception propagates up through handler.create_messages into the except Exception as e: at api_router.py:75. str(e) returns the exception message verbatim, including the address. The address ends up in the error.message field of the JSON response body returned to the attacker. ASLR entropy on the affected process drops from ~4 billion to ~8 candidates, identically to CVE-2026-22778 Stage 1.
The same primitive is reachable on POST /v1/messages/count_tokens (route #2), inside the SSE streaming converter when an exception is raised mid-stream (route #3), and over the realtime speech-to-text WebSocket when audio decoder or generation paths raise an exception containing any object repr (routes #4, #5).
Chronology — these are scope misses, not legacy code
- 2026-01-09: PR #31987 (
aa125ecf0) introducessanitize_messageand applies it to OpenAI router HTTP exception handlers. - 2026-01-15 (six days later): PR #32369 (
4c1c501a7) addsvllm/entrypoints/anthropic/api_router.pycontaining line 78'smessage=str(e). The fix was not applied to the new router. - 2026-03-02 (~two months later): PR #35588 (
9a87b0578) adds the Anthropiccount_tokensendpoint, replicating the samemessage=str(e)pattern at line 124. - 2026-05-12 (~four months later): PR #42370 (
d37e25ffb) consolidates speech-to-text entrypoints and the realtime WebSocket usessend_error(str(e), ...)for both error paths. - 2026-05-26: current
mainHEAD, all five lines still present.
CVSS v3.1
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N — Base 5.3 (MEDIUM)
The parent CVE-2026-22778 was 9.8 (CRITICAL) because it chained the Stage 1 leak with a Stage 2 libopenjp2 heap overflow. Stage 2 is patched in OpenCV ≥ 4.13.0 (PR #32668 bumped the requirement), so Stage 1 alone here is a partial ASLR-bypass info-disclosure primitive rather than a complete RCE. Deployments that ship vLLM alongside an older OpenCV/libopenjp2 (system OpenCV on long-LTS distros, custom Docker images, downstream rebuilds) re-enable the full chain via the affected endpoints.
CWE
CWE-532 (Insertion of Sensitive Information into Log File / Error Message). Same CWE assigned to the parent CVE-2026-22778.
Remediation
1. Apply sanitize_message symmetrically to the five sites
# vllm/entrypoints/anthropic/api_router.py — add at top:
from vllm.entrypoints.utils import sanitize_message
# Line 78 (POST /v1/messages) and Line 124 (count_tokens):
message=sanitize_message(str(e)),
# vllm/entrypoints/anthropic/serving.py — add at top:
from vllm.entrypoints.utils import sanitize_message
# Line 808:
error=AnthropicError(type="internal_error", message=sanitize_message(str(e))),
# vllm/entrypoints/speech_to_text/realtime/connection.py — add at top:
from vllm.entrypoints.utils import sanitize_message
# Lines 75 and 265:
await self.send_error(sanitize_message(str(e)), "processing_error")
2. Tighten the regex (defense in depth)
The current regex r" at 0x[0-9a-f]+>" is narrow — it only matches the exact CPython builtin object-repr suffix in lowercase hex with a trailing >. Future Python versions, C extensions, or custom __repr__ methods could produce non-matching formats that re-enable the leak:
# vllm/entrypoints/utils.py
def sanitize_message(message: str) -> str:
# Strip any standalone hex address; downstream observers don't need them.
return re.sub(r"\b0x[0-9a-fA-F]{6,}\b", "0x?", message)
3. Future-proofing: consider a response middleware
Both the route-local exception handling pattern (Anthropic router) and the WebSocket path bypass FastAPI's exception handler chain. A response-level middleware that always invokes sanitize_message on outgoing error bodies would prevent this class of regression entirely.
Affected versions
- All vLLM versions containing
vllm/entrypoints/anthropic/api_router.py(introduced 2026-01-15 in PR #32369). - All vLLM versions containing
vllm/entrypoints/speech_to_text/realtime/connection.py(introduced 2026-05-12 in PR #42370). - Confirmed present in
mainHEAD771e1e48b(2026-05-26).
References
- Parent advisory: https://github.com/vllm-project/vllm/security/advisories/GHSA-4r2x-xpjr-7cvv (CVE-2026-22778)
- Fix PRs to model the patch on: #31987, #32319, #32668
vllm/entrypoints/utils.py:sanitize_message: https://github.com/vllm-project/vllm/blob/771e1e48b/vllm/entrypoints/utils.py#L323-L326vllm/entrypoints/anthropic/api_router.pyleak site: https://github.com/vllm-project/vllm/blob/771e1e48b/vllm/entrypoints/anthropic/api_router.py#L78
Steps to reproduce
- Clone the target:
git clone --depth 1 https://github.com/vllm-project/vllm - Run the proof of concept (
PoC.py) against the cloned source. - Observe the result shown under Verified result below.
Credit
Kai Aizen — SnailSploit (@SnailSploit). Adversarial & Offensive Security Research.
Fix
A fix for this vulnerability was added here: https://github.com/vllm-project/vllm/pull/45119
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.0"
},
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54236"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T14:04:09Z",
"nvd_published_at": "2026-06-22T23:16:31Z",
"severity": "MODERATE"
},
"details": "# vLLM: incomplete CVE-2026-22778 fix leaks PIL repr addresses via the Anthropic API router\n\n**Researcher:** Kai Aizen \u2014 SnailSploit (@SnailSploit), Adversarial \u0026 Offensive Security Research\n**Severity:** CVSS 3.1 5.3 (Medium) `AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N`\n**Target:** https://github.com/vllm-project/vllm\n\n---\n\n## Summary\n\nThe fix for CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv (PRs #31987 and #32319) introduced `sanitize_message` and applied it at four FastAPI exception-handling sites in the OpenAI router. The sanitizer strips object-repr memory addresses (`\u003c_io.BytesIO object at 0x7a95e299e750\u003e` \u2192 `\u003c_io.BytesIO object\u003e`) before error messages reach the client, defeating the ASLR-bypass primitive that CVE-2026-22778 chained with a libopenjp2 heap overflow for RCE.\n\nThe fix is incomplete: response paths added to vLLM at or after the same time as the fix continue to echo `str(exc)` directly to clients without `sanitize_message`. The original Stage 1 primitive \u2014 sending malformed image bytes so PIL raises `UnidentifiedImageError` whose message contains the BytesIO object repr \u2014 reaches all of them unmodified and leaks the heap address verbatim in the response body.\n\nAll five lines below are present in `main` HEAD (`771e1e48b`, 2026-05-26).\n\n## Affected sites\n\nCurrent `main` HEAD (`771e1e48b`, 2026-05-26):\n\n| # | File | Line | Code |\n|---|---|---|---|\n| 1 | `vllm/entrypoints/anthropic/api_router.py` | 78 | `message=str(e),` (inside `POST /v1/messages` exception handler) |\n| 2 | `vllm/entrypoints/anthropic/api_router.py` | 124 | `message=str(e),` (inside `POST /v1/messages/count_tokens`) |\n| 3 | `vllm/entrypoints/anthropic/serving.py` | 808 | `error=AnthropicError(type=\"internal_error\", message=str(e)),` (SSE streaming converter) |\n| 4 | `vllm/entrypoints/speech_to_text/realtime/connection.py` | 75 | `await self.send_error(str(e), \"processing_error\")` (WebSocket event loop) |\n| 5 | `vllm/entrypoints/speech_to_text/realtime/connection.py` | 265 | `await self.send_error(str(e), \"processing_error\")` (WebSocket generation loop) |\n\n## Why the global exception handler does not save these paths\n\n`api_server.py` registers a catch-all `app.exception_handler(Exception)(exception_handler)` at line 262, and that handler calls `create_error_response(exc)` which DOES apply `sanitize_message`. However, FastAPI exception handlers fire only on **unhandled** exceptions that propagate out of a route function.\n\nAll affected HTTP paths catch `Exception` *inside* the route coroutine and construct the response themselves:\n\n```python\n# vllm/entrypoints/anthropic/api_router.py:71-81 (POST /v1/messages)\ntry:\n generator = await handler.create_messages(request, raw_request)\nexcept Exception as e:\n logger.exception(\"Error in create_messages: %s\", e)\n return JSONResponse(\n status_code=HTTPStatus.INTERNAL_SERVER_ERROR.value,\n content=AnthropicErrorResponse(\n error=AnthropicError(\n type=\"internal_error\",\n message=str(e), # \u003c-- unsanitized\n )\n ).model_dump(),\n )\n```\n\nBecause the exception is caught and a `JSONResponse` is returned in-route, every registered FastAPI exception handler \u2014 including the sanitizing global one \u2014 is bypassed. The WebSocket path bypasses it for a different reason: WebSocket frames don\u0027t traverse FastAPI\u0027s HTTP exception handler chain at all.\n\n## Reachability \u2014 the same primitive as the parent CVE\n\nThe Anthropic Messages API accepts image content parts in the request body (`type: \"image\"` with base64 `source.data` or `type: \"image_url\"`). Image bytes are passed to the same multimodal loader used by the OpenAI router. Malformed bytes cause `PIL.Image.open` to raise:\n\n```\nUnidentifiedImageError: cannot identify image file \u003c_io.BytesIO object at 0x7a95e299e750\u003e\n```\n\nThe exception propagates up through `handler.create_messages` into the `except Exception as e:` at `api_router.py:75`. `str(e)` returns the exception message verbatim, including the address. The address ends up in the `error.message` field of the JSON response body returned to the attacker. ASLR entropy on the affected process drops from ~4 billion to ~8 candidates, identically to CVE-2026-22778 Stage 1.\n\nThe same primitive is reachable on `POST /v1/messages/count_tokens` (route #2), inside the SSE streaming converter when an exception is raised mid-stream (route #3), and over the realtime speech-to-text WebSocket when audio decoder or generation paths raise an exception containing any object repr (routes #4, #5).\n\n## Chronology \u2014 these are scope misses, not legacy code\n\n- **2026-01-09:** PR #31987 (`aa125ecf0`) introduces `sanitize_message` and applies it to OpenAI router HTTP exception handlers.\n- **2026-01-15** (six days later): PR #32369 (`4c1c501a7`) adds `vllm/entrypoints/anthropic/api_router.py` containing line 78\u0027s `message=str(e)`. The fix was not applied to the new router.\n- **2026-03-02** (~two months later): PR #35588 (`9a87b0578`) adds the Anthropic `count_tokens` endpoint, replicating the same `message=str(e)` pattern at line 124.\n- **2026-05-12** (~four months later): PR #42370 (`d37e25ffb`) consolidates speech-to-text entrypoints and the realtime WebSocket uses `send_error(str(e), ...)` for both error paths.\n- **2026-05-26:** current `main` HEAD, all five lines still present.\n\n## CVSS v3.1\n\n`AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N` \u2014 Base 5.3 (MEDIUM)\n\nThe parent CVE-2026-22778 was 9.8 (CRITICAL) because it chained the Stage 1 leak with a Stage 2 libopenjp2 heap overflow. Stage 2 is patched in OpenCV \u2265 4.13.0 (PR #32668 bumped the requirement), so Stage 1 alone here is a partial ASLR-bypass info-disclosure primitive rather than a complete RCE. Deployments that ship vLLM alongside an older OpenCV/libopenjp2 (system OpenCV on long-LTS distros, custom Docker images, downstream rebuilds) re-enable the full chain via the affected endpoints.\n\n## CWE\n\nCWE-532 (Insertion of Sensitive Information into Log File / Error Message). Same CWE assigned to the parent CVE-2026-22778.\n\n## Remediation\n\n### 1. Apply `sanitize_message` symmetrically to the five sites\n\n```python\n# vllm/entrypoints/anthropic/api_router.py \u2014 add at top:\nfrom vllm.entrypoints.utils import sanitize_message\n\n# Line 78 (POST /v1/messages) and Line 124 (count_tokens):\nmessage=sanitize_message(str(e)),\n```\n\n```python\n# vllm/entrypoints/anthropic/serving.py \u2014 add at top:\nfrom vllm.entrypoints.utils import sanitize_message\n\n# Line 808:\nerror=AnthropicError(type=\"internal_error\", message=sanitize_message(str(e))),\n```\n\n```python\n# vllm/entrypoints/speech_to_text/realtime/connection.py \u2014 add at top:\nfrom vllm.entrypoints.utils import sanitize_message\n\n# Lines 75 and 265:\nawait self.send_error(sanitize_message(str(e)), \"processing_error\")\n```\n\n### 2. Tighten the regex (defense in depth)\n\nThe current regex `r\" at 0x[0-9a-f]+\u003e\"` is narrow \u2014 it only matches the exact CPython builtin object-repr suffix in lowercase hex with a trailing `\u003e`. Future Python versions, C extensions, or custom `__repr__` methods could produce non-matching formats that re-enable the leak:\n\n```python\n# vllm/entrypoints/utils.py\ndef sanitize_message(message: str) -\u003e str:\n # Strip any standalone hex address; downstream observers don\u0027t need them.\n return re.sub(r\"\\b0x[0-9a-fA-F]{6,}\\b\", \"0x?\", message)\n```\n\n### 3. Future-proofing: consider a response middleware\n\nBoth the route-local exception handling pattern (Anthropic router) and the WebSocket path bypass FastAPI\u0027s exception handler chain. A response-level middleware that always invokes `sanitize_message` on outgoing error bodies would prevent this class of regression entirely.\n\n## Affected versions\n\n- All vLLM versions containing `vllm/entrypoints/anthropic/api_router.py` (introduced 2026-01-15 in PR #32369).\n- All vLLM versions containing `vllm/entrypoints/speech_to_text/realtime/connection.py` (introduced 2026-05-12 in PR #42370).\n- Confirmed present in `main` HEAD `771e1e48b` (2026-05-26).\n\n## References\n\n- Parent advisory: https://github.com/vllm-project/vllm/security/advisories/GHSA-4r2x-xpjr-7cvv (CVE-2026-22778)\n- Fix PRs to model the patch on: #31987, #32319, #32668\n- `vllm/entrypoints/utils.py:sanitize_message`: https://github.com/vllm-project/vllm/blob/771e1e48b/vllm/entrypoints/utils.py#L323-L326\n- `vllm/entrypoints/anthropic/api_router.py` leak site: https://github.com/vllm-project/vllm/blob/771e1e48b/vllm/entrypoints/anthropic/api_router.py#L78\n\n## Steps to reproduce\n\n1. Clone the target: `git clone --depth 1 https://github.com/vllm-project/vllm`\n2. Run the proof of concept (`PoC.py`) against the cloned source.\n3. Observe the result shown under *Verified result* below.\n\n## Credit\n\nKai Aizen \u2014 SnailSploit (@SnailSploit). Adversarial \u0026 Offensive Security Research.\n\n## Fix\n\nA fix for this vulnerability was added here: https://github.com/vllm-project/vllm/pull/45119",
"id": "GHSA-hgg8-fqqc-vfmw",
"modified": "2026-07-20T13:36:37Z",
"published": "2026-06-17T14:04:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-hgg8-fqqc-vfmw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54236"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/45119"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/94923629729381d7f7c9efde72071a2441f7fd82"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-hgg8-fqqc-vfmw"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-3408.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://pypi.org/project/vllm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "vLLM: incomplete CVE-2026-22778 fix leaks PIL repr addresses via Anthropic router"
}
Mitigation
Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
Mitigation
Remove debug log files before deploying the application into production.
Mitigation
Protect log files against unauthorized read/write.
Mitigation
Adjust configurations appropriately when software is transitioned from a debug state to production.
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.