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:[email protected]
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 [email protected] 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:[email protected]
CWE: CWE-453 — Insecure Default Variable Initialization
CVSS: 9.8
Priority Score: 704
Source: Transitive dependency via [email protected]

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 [email protected] 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 -->

Enter fullscreen mode Exit fullscreen mode

Option B — Explicitly disable AJP in application configuration:

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

Enter fullscreen mode Exit fullscreen mode

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:[email protected]
CWE: CWE-502 — Deserialization of Untrusted Data
CVSS: 9.2
Priority Score: 889
Source: Transitive dependency via both [email protected] AND io.jsonwebtoken:[email protected]

This finding appears multiple times in the Snyk output — because [email protected] 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 [email protected] 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;
}

Enter fullscreen mode Exit fullscreen mode

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

Package: org.springframework.boot:[email protected]
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

Enter fullscreen mode Exit fullscreen mode

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:[email protected]
CWE: CWE-285 — Improper Authorization
CVSS: 8.2
Priority Score: 731
Source: Transitive dependency via [email protected]

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());
}

Enter fullscreen mode Exit fullscreen mode

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:[email protected]
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 [email protected] 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>

Enter fullscreen mode Exit fullscreen mode

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 — particularly the large number of Spring Framework and Spring Boot component CVEs — are resolved automatically when the parent BOM is upgraded to Spring Boot 3.2.5. I'll show the exact count in article 6.

Lower severity findings with no exploit code. The 137 findings with "no known exploit" in the exploit maturity classification are real vulnerabilities, but their practical risk is lower. An attacker needs to develop custom exploit code to leverage them, compared to downloading a working tool for the 8 findings with mature exploits. These get tracked but don't drive remediation urgency.

Accepted risk findings. A small number of findings — which I'll discuss in detail in article 4 — represent vulnerabilities that either can't be exploited in MFlix's specific deployment context, require conditions that don't exist in the application, or have remediation paths that introduce more risk than they resolve. These get documented suppression decisions rather than patches.

Reading Snyk Findings Like an AppSec Engineer

The biggest shift in how I read the Snyk output now versus how I would have read it before this project is the difference between asking "what does this flag?" and "what can an attacker do?"

CVSS scores are a starting point. They represent the worst-case severity of the vulnerability in a generic context. But the actual risk to any specific application depends on:

Reachability — Is the vulnerable code path reachable from the application's attack surface? The RCE in spring-beans is reachable because MFlix exposes public HTTP endpoints. A vulnerability in a batch processing library that only runs scheduled jobs has a much smaller attack surface.

Exploit availability — Is there working exploit code publicly available? The 8 findings with mature exploits are categorically different from the 137 with no known exploit, regardless of their CVSS scores.

Application-specific amplification — Does the application's functionality make the vulnerability worse? The jackson-databind deserialization vulnerability is more dangerous in an application that accepts complex JSON structures from untrusted users (like MFlix's comment and registration endpoints) than in an application that only produces JSON.

Compensating controls — What else is between the attacker and the vulnerable component? Network-level controls, WAF rules, and rate limiting all affect the practical exploitability of vulnerabilities that require repeated requests or specific network positions.

Reading Snyk output through these four lenses — rather than sorting by CVSS and fixing from the top — is what produces a defensible remediation strategy rather than a checkbox exercise.

The full Snyk project for MFlix is at github.com/pgmpofu/mflix.

Next up: why I suppressed some findings and fixed others — the risk assessment framework, the role of exploit maturity, and the specific decisions I made on the findings that didn't get a patch.