CVE-2018-1270 in Spring Framework: Affected Versions and How to Check

CVE-2018-1270 is a vulnerability in Spring Framework's spring-messaging module. The most confusing part when researching it is whether the fix is 4.3.15 or 4.3.16, because NVD's description and the vendor advisory disagree. This article reconciles the primary sources and lays out the affected and fixed versions plus how to tell whether your environment is affected.

At a glance

What the vulnerability is

The official Spring advisory describes it as follows.

Spring Framework, versions 5.0.x prior to 5.0.5 and versions 4.3.x prior to 4.3.16, and older unsupported versions allow 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 remote code execution attack.

In other words, the exposure arises where an application exposes a STOMP over WebSocket endpoint through the spring-messaging module and uses the simple in-memory broker rather than relaying to an external broker. A crafted message sent to that broker can lead to remote code execution.

So using Spring Framework is not by itself enough to be affected. Whether your configuration matches the conditions above is what decides it. The advisory cites two references: the Spring reference documentation on enabling STOMP over WebSocket, and the Spring Security reference on WebSocket (URLs at the end of this article).

The fixed 4.3.x version is 4.3.16, not 4.3.15

This is the easiest thing to get wrong about this CVE. The NVD description still reads "versions 4.3 prior to 4.3.15", which is the original wording from publication. The History section of the official Spring advisory records:

• 2018-04-05: Initial vulnerability report published.
• 2018-04-10: Replaced upgrade version 4.3.15 with 4.3.16 due to CVE-2018-1275

The originally advised 4.3.15 was withdrawn because of a separate vulnerability (CVE-2018-1275) and replaced by 4.3.16. NVD's own CPE data agrees with the vendor even though its prose does not: the applicability range is "anything below 4.3.16 is vulnerable".

If you are on the 4.3 line, upgrading to 4.3.15 does not count as remediation. Go to 4.3.16 or later.

How to check whether you are affected

Everything below is a check you run against an environment you own.

1. Find the Spring Framework version actually in use

Check the version your application really resolves to, using your build tool's dependency tree. Parent POMs and BOMs can make the declared version differ from the resolved one, so look at what is resolved, not what is declared.

# Maven: check the resolved spring-messaging and spring-core versions
mvn dependency:tree -Dincludes=org.springframework

# Gradle: check what the runtime classpath resolves to
./gradlew dependencies --configuration runtimeClasspath

If you only have a built artifact, the bundled JAR filename (spring-messaging-x.y.z.jar) or the Implementation-Version entry in the JAR's META-INF/MANIFEST.MF also gives you the version.

2. Check whether you use the affected feature

Even a version inside the affected range is not exposed unless the configuration described by the advisory is in use. Confirm three things from your configuration and code.

• Whether spring-messaging is on the classpath (check the dependency tree).
• Whether you expose a STOMP over WebSocket endpoint at all. If not, this path does not exist in your application.
• Whether that endpoint uses the simple in-memory broker or relays to an external message broker. The advisory concerns the former.

3. Check whether message authentication and authorization are in place

The advisory notes:

Note that the use of authentication and authorization for messages, both of which are provided by Spring Security, limits exposure to this vulnerability to authorized users.

Where message authentication and authorization (both provided by Spring Security) are used, exposure is limited to authorized users. That narrows the blast radius, but the advisory does not present it as a workaround. The remediation is the upgrade described next.

What the vendor says to do

The advisory's mitigation section is brief:

• Users of affected versions should upgrade to the corresponding fixed version.
• There are no other mitigation steps necessary.

That is, move the 5.0.x line to 5.0.5 and the 4.3.x line to 4.3.16, with no other mitigation required. Note that both fixed versions belong to lines that went out of support many years ago. If you are still on 4.3.x or 5.0.x, this is a moment to consider migrating to a supported line rather than just patching this one CVE.

Is it known to be exploited?

Searching CISA's Known Exploited Vulnerabilities catalog directly on 4 August 2026 (catalog version 2026.08.03, 1,657 entries), CVE-2018-1270 was not listed. The NVD record likewise carries no KEV-related fields.

NVD's reference list does include an Exploit Database entry, tagged "Broken Link / Third Party Advisory / VDB Entry". That tells you public proof-of-concept code existed historically, which is a different matter from KEV listing. The vendor advisory itself makes no claim about exploitation.

Watch out for downstream products

Besides Spring Framework itself, NVD lists redistributing products as vulnerable. At the time of checking these included Red Hat Fuse, Debian GNU/Linux 9 and a large number of Oracle products (Communications, Retail, Primavera, GoldenGate, Application Testing Suite and others). Even if you do not use Spring directly, you may be affected through a bundled copy inside a vendor product. For those, check that vendor's own advisory.