`@PostMapping("/users") public User create(@RequestBody User user) { return users.save(user); }` — the `User` entity has a `role` field with a public setter, because Hibernate's mapping needs one. What's the actual vulnerability here, and why does switching to a request DTO with only `name` and `email` fix more than just the `role` field?

Jackson binds every JSON key the client sends onto a matching writable property on the target class, with no allow-list by default — so a client can send {"name":"ana","role":"ADMIN"}, and Jackson sets role exactly as happily as it sets name, because from Jackson's point of view they're both just writable fields on User. This is mass assignment, the API-specific twin of broken access control: binding a request body directly to the entity Hibernate persists means every public setter that class has for persistence's sake is also, mechanically, part of the API's write surface — whether or not anyone intended that. Switching to a CreateUserRequest DTO that declares only name and email fixes the whole class of problem at once, not just role: there's no role property on that class for any JSON key to bind to, so it doesn't matter what a client sends.