CVE-2018-1270 is a critical, unauthenticated remote code execution vulnerability in the Spring Framework's messaging stack — specifically in how applications built on spring-messaging handle STOMP frames delivered over WebSocket to an in-memory message broker. An attacker who can reach a vulnerable WebSocket/STOMP endpoint can send a specially crafted message and achieve arbitrary code execution on the server, with no authentication and no user interaction required. Because Spring's WebSocket messaging support is commonly wired into chat features, real-time dashboards, notification systems, and trading/telemetry backends, this flaw sat squarely in the path of internet-facing Java applications when it was disclosed — and it remains a useful case study in why "just a messaging library" can turn into a full server compromise.
What the vulnerability is
Per the official advisory from Pivotal (now VMware Tanzu), the issue affects applications that use the Spring Messaging module's STOMP-over-WebSocket support — the code path enabled when an application configures @EnableWebSocketMessageBroker and relies on Spring's simple, in-memory STOMP broker relay to route messages between connected clients. The advisory describes the flaw plainly: applications using this configuration "are vulnerable to a remote code execution attack." In practice, this means any service exposing a STOMP endpoint to untrusted clients — even ones behind a login page, since the flaw doesn't require valid credentials to trigger — inherited a path to full compromise simply by including a vulnerable version of the framework.
This is the kind of vulnerability that's easy to miss in a manual review because it doesn't live in application code at all. Developers wire up spring-messaging and spring-websocket to support a chat widget or a live-updating UI, never touch the internals of STOMP frame handling, and have no reason to suspect the transport layer itself is the attack surface. That's precisely why it's a supply-chain-relevant CVE rather than a typical "you wrote insecure code" bug: the vulnerable logic ships inside the dependency, and every application that pulls it in — directly or transitively through spring-boot-starter-websocket — inherits the exposure automatically.
Affected versions and components
The advisory identifies the following as affected:
- Spring Framework 5.0.x prior to 5.0.6
- Spring Framework 4.3.x prior to 4.3.17
- Older, unsupported Spring Framework release lines (pre-4.3), which were never patched because they had already reached end of life
The vulnerable component is the spring-messaging module, specifically its STOMP-over-WebSocket support used in conjunction with Spring's simple broker configuration. Applications are exposed when they enable WebSocket messaging via Spring's messaging annotations and configuration classes and accept STOMP connections from clients that cannot be fully trusted (which, for anything internet-facing, is effectively all clients).
It's worth noting that spring-messaging is frequently a transitive dependency — pulled in automatically by spring-boot-starter-websocket or similar starters — rather than something teams declare and version-pin explicitly. That makes it a classic candidate for going unnoticed in manual dependency reviews and for lingering in build artifacts long after the direct Spring Framework version has been bumped elsewhere in a project.
CVSS, EPSS, and KEV context
NVD rates CVE-2018-1270 as Critical, with a CVSS v3 base score of 9.8 — reflecting a network-exploitable vulnerability with low attack complexity, no privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. That combination (unauthenticated, remote, full compromise) is what pushes a CVE to the top of the severity scale, and it's consistent with several other Spring ecosystem RCEs disclosed around the same period, such as CVE-2018-1273 in Spring Data Commons.
On exploitability signals: CVE-2018-1270 is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, which tracks vulnerabilities with confirmed evidence of active, in-the-wild exploitation. That's not the same as saying it's harmless — plenty of critical, high-EPSS vulnerabilities never make the KEV list simply because CISA's inclusion criteria require documented exploitation evidence, and older CVEs in already-patched software attract less fresh attacker interest over time. Given the CVE's age (2018) and the fact that most actively maintained Spring deployments have long since moved past the vulnerable release lines, current real-world exploitation activity is comparatively low — but that's a reflection of shrinking exposed attack surface, not of the flaw being any less severe on paper. Any application still running an unpatched, internet-facing Spring Messaging STOMP endpoint today should treat this as an immediate, critical-priority finding, not a historical footnote.
Timeline
- Pre-disclosure: The vulnerability was identified and reported through Pivotal's responsible disclosure process for the Spring portfolio, alongside a batch of other Spring Framework and Spring Data CVEs disclosed in the same window (a common pattern for the Spring Security team, which frequently ships coordinated advisories covering multiple related issues).
- April 2018: Pivotal published the fix as part of Spring Framework 5.0.6 and 4.3.17, along with the corresponding security advisory describing the STOMP-over-WebSocket remote code execution issue.
- 2018, shortly after: CVE-2018-1270 was published in the National Vulnerability Database with its Critical severity rating, and the finding was incorporated into standard SCA and vulnerability-scanning tool feeds (dependency-check, Snyk, commercial SCA products, etc.).
- Ongoing: The CVE continues to surface in dependency audits today whenever legacy services are found running pre-5.0.6 / pre-4.3.17 Spring Framework versions, particularly in older internal tools, long-lived monoliths, and vendor appliances built on outdated Spring Boot parent versions that were never upgraded.
Remediation steps
- Upgrade the Spring Framework version. Move to Spring Framework 5.0.6 or later within the 5.0.x line, or 4.3.17 or later within the 4.3.x line, as the minimum patched baseline. In practice, neither of those lines is still supported today — teams should target a current, actively maintained Spring Framework release (5.3.x or the 6.x line) rather than stopping at the historical minimum fix.
- Upgrade Spring Boot, not just Spring Framework. Because
spring-messagingis usually pulled in transitively viaspring-boot-starter-websocket, confirm which Spring Boot parent/BOM version your project uses and upgrade to a release train that bundles a patched Spring Framework version, rather than attempting to override the transitive dependency version in isolation. - Audit for transitive exposure. Run a full dependency tree resolution (
mvn dependency:tree/gradle dependencies) to confirm the resolvedspring-messagingandspring-websocketversions across every module and microservice — not just the ones your team owns directly. Vulnerable versions frequently hide in shared internal libraries or vendored starter POMs. - Restrict exposure where upgrading isn't immediately possible. If a patch can't be deployed right away, place STOMP/WebSocket endpoints behind network controls that limit access to trusted sources, and consider disabling the simple in-memory broker relay for internet-facing deployments until the upgrade lands.
- Re-scan after remediation. Confirm the fix with an SBOM or SCA re-scan against the deployed artifact — not just the source repository — since build caches, container base images, and CI artifact stores can retain vulnerable jars even after source-level dependency declarations are updated.
How Safeguard helps
CVE-2018-1270 is exactly the kind of finding that gets missed by point-in-time audits and caught by continuous software supply chain visibility: a transitive, deeply-nested dependency, disclosed years ago, that quietly persists in build artifacts, container images, and vendor components long after anyone remembers configuring it.
Safeguard is built to close that gap. Our platform continuously generates and monitors SBOMs across your build pipelines, so spring-messaging and every other transitive dependency — not just the libraries declared in a top-level pom.xml — are inventoried automatically and matched against known CVEs like this one as soon as they're published or as soon as a new artifact is built. Rather than waiting for a scheduled scan to surface a critical unauthenticated RCE, Safeguard flags vulnerable versions the moment they enter your software supply chain, correlates severity and exploitability context (CVSS, EPSS, and KEV status) so teams can prioritize what actually matters, and tracks remediation through to a verified patched build.
For organizations managing SOC 2 or similar compliance obligations, Safeguard also maintains the audit trail proving that vulnerable components were identified, tracked, and remediated in a timely manner — turning a finding like CVE-2018-1270 from a manual fire drill into a routine, provable part of your ongoing supply chain security posture.