Running Snyk on Real Legacy Java Code - The Full Unfiltered Results

Numbers are easy to skim. 10 Critical. 99 High. 59 Medium. 20 Low. 188 total. Those numbers appeared in the first article and they're striking - but they don't tell you what an attacker could actually do with them. This article is the deep dive.

I'm going to take the most significant findings from the Snyk scan of MFlix and explain what each vulnerability actually enables, why it matters specifically for this application's threat model, and what the relationship is between the dependency version and the attack. Not all 188 findings - the ones that matter. The ones with working exploit code. The ones with CVSS scores above 9.0. The ones where the application's specific functionality intersects with the vulnerability in a way that makes it genuinely dangerous.

The Threat Model First

Before talking about individual vulnerabilities, it's worth being explicit about what MFlix actually is and who would be attacking it.

MFlix is a web application with:

• A public endpoint for movie search (unauthenticated)
• A user registration and login endpoint (unauthenticated)
• Authenticated endpoints for posting comments and accessing user data
• A MongoDB Atlas backend
• JWT-based session management
• A Spring Security access control layer

The realistic threat actors are:

• Automated vulnerability scanners looking for known CVEs
• Attackers who have identified the Spring Boot version via response headers and are targeting known exploits
• Authenticated users attempting privilege escalation
• Network-layer attackers attempting to intercept database traffic

With that model established, here's what the findings actually mean.

Finding 1: Remote Code Execution in spring-beans - CVSS 9.8

• Package: org.springframework:sp**********@5.0.7.RELEASE
• CWE: CWE-94 - Improper Control of Generation of Code
• CVSS: 9.8
• Priority Score: 919
• Exploit maturity: Proof of concept available

This is the finding that made me stop and re-read the output twice. Remote Code Execution means an attacker can execute arbitrary commands on the server running the application. CVSS 9.8 is one point below the theoretical maximum. This is not a "could potentially lead to" vulnerability - it is a "an attacker who can reach this endpoint can run code on your server" vulnerability.

What the vulnerability is: The Spring Framework's CachedIntrospectionResults class, which handles JavaBean property introspection, improperly handles class loading in certain configurations. An attacker who can craft a malicious request containing a specific class path expression can cause the application to load and execute attacker-controlled code. This is related to - but distinct from - Spring4Shell (CVE-2022-22965), which made significant news in 2022. Spring4Shell required specific conditions: Java 9+, Spring Framework 5.3.x or 5.2.x, deployed as a WAR on Tomcat, with specific Spring MVC configurations. The RCE in spring-beans@5.0.7 has different preconditions but the same fundamental class of vulnerability.

Why it matters for MFlix specifically: MFlix exposes public HTTP endpoints - the movie search and authentication endpoints don't require a logged-in user. An attacker with network access doesn't need credentials to reach the vulnerable code path. The attack surface is the public-facing API.

The fix: Upgrading spring-web to 5.2.20.RELEASE or later resolves this. Under the BOM approach from article 2, this happens automatically when you upgrade to Spring Boot 2.7.x or 3.x.

Finding 2: Insecure Defaults in tomcat-embed-core - CVSS 9.8

• Package: org.apache.tomcat.embed:tomcat-embed-core@8.5.31
• CWE: CWE-453 - Insecure Default Variable Initialization
• CVSS: 9.8
• Priority Score: 704
• Source: Transitive dependency via spring-boot-starter-web@2.0.3

This finding arrives through a transitive dependency - you never see tomcat-embed-core in the pom.xml, but it's the embedded servlet container that Spring Boot uses to serve HTTP requests. Every Spring Boot web application embeds Tomcat by default.

What the vulnerability is: Tomcat 8.5.31 ships with insecure default configurations in its AJP (Apache JServ Protocol) connector. AJP is a binary protocol used for communication between a web server (like Apache httpd) and Tomcat. In certain deployment configurations, the AJP connector accepts connections without sufficient authentication, allowing an attacker to read arbitrary files from the server and potentially achieve remote code execution. This vulnerability is related to the "Ghostcat" class of vulnerabilities (CVE-2020-1938) that affected Tomcat's AJP connector.

Why it matters for MFlix: In a typical development or cloud deployment, the AJP connector would be disabled entirely. But tomcat-embed-core@8.5.31 enables it by default. A developer who deploys MFlix without explicitly disabling AJP is running an exposed connector. The application.properties in the original MFlix doesn't disable AJP. That's an omission that creates real attack surface.

The fix: Option A - Upgrade to a fixed Tomcat version (handled by BOM upgrade):

<!-- Spring Boot 3.x pulls in Tomcat 10.x, which addresses this -->

Option B - Explicitly disable AJP in application configuration:

# application.properties
server.tomcat.ajp.enabled = false

The BOM upgrade resolves this automatically, but the explicit disable is worth adding regardless - it's defence in depth and makes the intent clear.

Finding 3: Deserialization of Untrusted Data in jackson-databind - CVSS 9.2

• Package: com.fasterxml.jackson.core:jackson-databind@2.9.6
• CWE: CWE-502 - Deserialization of Untrusted Data
• CVSS: 9.2
• Priority Score: 889
• Source: Transitive dependency via both spring-boot-starter-web@2.0.3 AND io.jsonwebtoken:jjwt@0.9.1

This finding appears multiple times in the Snyk output - because jackson-databind@2.9.6 is a transitive dependency of multiple direct dependencies. When the same vulnerable library is pulled in through different dependency paths, Snyk correctly reports it once per path.

What the vulnerability is: Jackson's polymorphic deserialization feature, when enabled with the @JsonTypeInfo annotation or default typing, allows an attacker who controls JSON input to instantiate arbitrary Java classes. Certain "gadget" classes in common Java libraries - classes that perform dangerous operations in their constructors or setters - can be chained together to achieve remote code execution when they're instantiated during deserialization.

The attack pattern:

1. Application accepts JSON input from a user
2. That JSON is deserialized using Jackson with polymorphic typing enabled
3. Attacker crafts JSON that specifies a malicious class type
4. Jackson instantiates the attacker-specified class, triggering its constructor
5. The constructor performs a dangerous operation - file write, network connection, command execution

Why it matters for MFlix specifically: MFlix's comment posting endpoint accepts JSON. The user registration endpoint accepts JSON. If the deserialization configuration on any of these endpoints uses polymorphic typing without blocklisting dangerous classes, the attack surface is real. The jjwt@0.9.1 dependency is the more concerning vector here. JWT parsing involves deserialization of the JWT payload. If the JWT library delegates to Jackson for payload deserialization and the Jackson configuration is permissive, an attacker who can forge a JWT - or who can supply a malicious token that reaches the parsing code before signature verification - could trigger the deserialization vulnerability. This is why the jjwt→0.12.0 upgrade matters beyond just the CVSS score. The new library was explicitly rewritten to avoid this deserialization path.

The fix: Upgrade jackson-databind to 2.13.x or later (handled by BOM upgrade). Explicitly disable default typing in Jackson configuration as defence in depth:

@Bean
public ObjectMapper objectMapper() {
  ObjectMapper mapper = new ObjectMapper();
  // Explicitly disable default typing to prevent gadget attacks
  mapper.deactivateDefaultTyping();
  return mapper;
}

Finding 4: Certificate Host Mismatch in spring-boot-autoconfigure - CVSS 9.3

• Package: org.springframework.boot:sprin********************@2.0.3.RELEASE
• CWE: CWE-297 - Improper Validation of Certificate with Host Mismatch
• CVSS: 9.3
• Priority Score: 679

This finding is the one most specific to MFlix's architecture - and the one I'd argue is most dangerous in practice despite not having the RCE severity of finding 1.

What the vulnerability is: Spring Boot's autoconfiguration for SSL/TLS connections, in version 2.0.3, improperly validates the hostname in TLS certificates. When the application makes outbound connections - to the MongoDB Atlas cluster, to external APIs, to any HTTPS endpoint - it may accept certificates where the hostname doesn't match the certificate's Common Name or Subject Alternative Names. In plain terms: the application might connect to attacker.com while believing it's connected to cluster.mongodb.net.

Why it matters for MFlix specifically: MFlix's entire data layer connects to MongoDB Atlas over TLS. Every database query goes through this connection. If the autoconfigure TLS validation is improperly validating the Atlas certificate, a network-position attacker - someone on the same network segment, or with DNS control, or with BGP hijacking capability - could intercept the database connection. What would they see? Every MongoDB query the application sends. Every result it receives. User credentials stored in the database. User session tokens. Movie data. Comment content. Everything. This isn't a theoretical attack in cloud environments - misconfigured network routing, shared hosting scenarios, and developer environments with local DNS modification are all realistic scenarios where this attack path is viable.

The fix: BOM upgrade to Spring Boot 2.5.x or later resolves the autoconfigure TLS validation. Additionally, explicitly configure SSL validation in the MongoDB connection:

# application.properties
spring.data.mongodb.uri = ${MONGODB_URI}&ssl=true&sslInvalidHostNameAllowed=false

The sslInvalidHostNameAllowed=false is the critical flag - it explicitly disables the insecure behaviour that the autoconfigure vulnerability enables.

Finding 5: Authorization Bypass in spring-security-web - CVSS 8.2

• Package: org.springframework.security:spri***************@5.0.7.RELEASE
• CWE: CWE-285 - Improper Authorization
• CVSS: 8.2
• Priority Score: 731
• Source: Transitive dependency via spring-boot-starter-security@2.0.4

This finding is particularly relevant for MFlix because MFlix uses Spring Security as its primary access control mechanism.

What the vulnerability is: Spring Security's path matching logic, in certain versions, could be bypassed by request paths that contain specific special characters or path traversal sequences. An attacker could access endpoints that should require authentication by crafting a URL that matches the underlying resource but doesn't match Spring Security's access control patterns. For example, if Spring Security protects /api/v1/users/profile but the path matching doesn't normalise path traversal sequences, a request to /api/v1/users/./profile might reach the endpoint without authentication.

Why it matters for MFlix specifically: MFlix's security configuration has:

• /api/v1/movies/** - public
• /api/v1/users/login - public
• Everything else - requires authentication

An authorization bypass vulnerability means the "everything else requires authentication" rule might have holes. User profile data, comment management, and administrative functionality could potentially be accessed without a valid JWT.

The fix: Spring Security 5.7.x and later include significantly improved path normalisation. The BOM upgrade handles this, but it's worth explicitly testing authentication enforcement after the upgrade:

// Test that authenticated endpoints reject unauthenticated requests
@Test
void unauthorizedAccessShouldReturn401() {
  mockMvc.perform(get("/api/v1/users/profile"))
    .andExpect(status().isUnauthorized());
}

// Test that path traversal attempts are rejected
@Test
void pathTraversalShouldBeRejected() {
  mockMvc.perform(get("/api/v1/users/../admin/users"))
    .andExpect(status().isForbidden());
}

These tests should exist regardless of whether the vulnerability is present - they're part of the security test baseline for any authenticated application.

Finding 6: Man-in-the-Middle in mongodb-driver-sync - CVSS 6.4

• Package: org.mongodb:mongodb-driver-sync@3.9.1
• CWE: CWE-300 - Channel Accessible by Non-Endpoint
• CVSS: 6.4
• Priority Score: 534

This is the only direct dependency finding that isn't in the Spring ecosystem. The MongoDB Java driver version 3.9.1 has a vulnerability in how it handles TLS connections to the MongoDB server.

What the vulnerability is: The driver, in certain connection configurations, doesn't enforce strict certificate chain validation for its TLS connections. An attacker in a network-privileged position - same network segment, DNS poisoning, BGP hijacking - could present a fraudulent certificate and establish a man-in-the-middle position between the application and the database.

Why it matters for MFlix: Combined with finding 4 (the autoconfigure certificate mismatch), this creates a layered TLS validation problem. The autoconfigure layer doesn't validate the host properly, and the driver layer doesn't enforce strict certificate chain validation. In a vulnerable deployment, both controls that should prevent a MitM attack are weakened.

The fix: Upgrade to mongodb-driver-sync@4.9.x or later (the 3.x to 4.x upgrade is a breaking change with significant API differences, which is why it appears in the "breaking changes" section of article 5):

<dependency>
  <groupId>org.mongodb</groupId>
  <artifactId>mongodb-driver-sync</artifactId>
  <version>4.11.1</version>
</dependency>

The Findings That Didn't Make This List

A natural question: what about the other 182 findings I haven't discussed? They fall into three categories.

• Handled by the BOM upgrade. The majority of findings.