Common Weakness Enumeration

CWE-838

Allowed

Inappropriate Encoding for Output Context

Abstraction: Base · Status: Incomplete

The product uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component.

21 vulnerabilities reference this CWE, most recent first.

GHSA-XVR9-35CR-46V9

Vulnerability from github – Published: 2026-08-28 22:47 – Updated: 2026-08-28 22:47
VLAI
Summary
org.mariadb.jdbc:mariadb-java-client has Inappropriate Encoding for Output Context
Details

Summary

The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change character_set_client mid-session to a non-UTF-8 charset, after which the driver and server interpret the same bytes under different encodings, causing silent data corruption and a client/server charset-confusion mismatch.

Details

The driver encodes and decodes all character data on the assumption that the connection character set is UTF-8. Charset can be changed by commands like SET NAMES... commands.

If the new charset is not UTF-8, the driver continues to read and write UTF-8 while the server interprets the same bytes under a different encoding. The result is silent data corruption and a client/server charset-confusion mismatch. Charset confusion of this kind is also the primitive that can defeat byte-wise quoting/escaping when client and server disagree on a multi-byte encoding.

Impact

Silent data corruption and a client/server encoding mismatch once the connection's charset diverges from UTF-8. Because the mismatch undermines the assumption that quoting/escaping operates on UTF-8 bytes, it belongs to the charset-confusion class that can lead to SQL injection.

Patches

Fixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x → 3.5.9, 3.4.x → 3.4.3, 3.0/3.1/3.2/3.3.x → 3.3.5, 2.x → 2.7.14). Once the connection is fully initialized, any subsequent charset change to a value that is not utf8 / utf8mb3 / utf8mb4 is rejected: the driver raises a SQLException with SQLState 08000 (connection exception) and closes the connection rather than continuing to exchange data under a mismatched encoding.

Workarounds

There is no reliable application-level workaround.

Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.0"
            },
            {
              "fixed": "3.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-838"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T22:47:19Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change character_set_client mid-session to a non-UTF-8 charset, after which the driver and server interpret the same bytes under different encodings, causing silent data corruption and a client/server charset-confusion mismatch.\n\n### Details\n\nThe driver encodes and decodes all character data on the assumption that the connection character set is UTF-8. \nCharset can be changed by commands like SET NAMES... commands.\n\nIf the new charset is not UTF-8, the driver continues to read and write UTF-8 while the server interprets the same bytes under a different encoding. The result is silent data corruption and a client/server charset-confusion mismatch. Charset confusion of this kind is also the primitive that can defeat byte-wise quoting/escaping when client and server disagree on a multi-byte encoding.\n\n### Impact\n\nSilent data corruption and a client/server encoding mismatch once the connection\u0027s charset diverges from UTF-8. Because the mismatch undermines the assumption that quoting/escaping operates on UTF-8 bytes, it belongs to the charset-confusion class that can lead to SQL injection.\n\n### Patches\n\nFixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x \u2192 3.5.9, 3.4.x \u2192 3.4.3, 3.0/3.1/3.2/3.3.x \u2192 3.3.5, 2.x \u2192 2.7.14). Once the connection is fully initialized, any subsequent charset change to a value that is not utf8 / utf8mb3 / utf8mb4 is rejected: the driver raises a SQLException with SQLState 08000 (connection exception) and closes the connection rather than continuing to exchange data under a mismatched encoding.\n\n### Workarounds\n\nThere is no reliable application-level workaround.\n\n### Credit\n\nReported by Yalguun Tumenkhuu ([@fg0x0](https://github.com/fg0x0/)).",
  "id": "GHSA-xvr9-35cr-46v9",
  "modified": "2026-08-28T22:47:19Z",
  "published": "2026-08-28T22:47:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/security/advisories/GHSA-xvr9-35cr-46v9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/commit/300716bef1e1d0370a41be7863b88aa2d55fbb69"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/commit/7b3c69221b5463ee03472654040b3f6b9e5329c7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/commit/8cfd9df697372ad4ed09fe87a34b34babb6d43d6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/commit/c555c9b477521be0c35c3a5461f9f46681553607"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/releases/tag/2.7.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/releases/tag/3.3.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/releases/tag/3.4.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/releases/tag/3.5.9"
    },
    {
      "type": "WEB",
      "url": "https://jira.mariadb.org/browse/CONJ-1317"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "org.mariadb.jdbc:mariadb-java-client has Inappropriate Encoding for Output Context"
}

Mitigation
Implementation

Strategy: Output Encoding

Use context-aware encoding. That is, understand which encoding is being used by the downstream component, and ensure that this encoding is used. If an encoding can be specified, do so, instead of assuming that the default encoding is the same as the default being assumed by the downstream component.

Mitigation
Architecture and Design

Strategy: Output Encoding

Where possible, use communications protocols or data formats that provide strict boundaries between control and data. If this is not feasible, ensure that the protocols or formats allow the communicating components to explicitly state which encoding/decoding method is being used. Some template frameworks provide built-in support.

Mitigation MIT-4.3
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
  • Note that some template mechanisms provide built-in support for the appropriate encoding.
CAPEC-468: Generic Cross-Browser Cross-Domain Theft

An attacker makes use of Cascading Style Sheets (CSS) injection to steal data cross domain from the victim's browser. The attack works by abusing the standards relating to loading of CSS: 1. Send cookies on any load of CSS (including cross-domain) 2. When parsing returned CSS ignore all data that does not make sense before a valid CSS descriptor is found by the CSS parser.