This bears some resemblance to the SQL Injection, only now because of an automation that a framework provides to decrease coding work. It usually occurs with MVC and ORM.
What usually happens is that what comes from the URL is deserialized to an object that is later persisted in the database. If you don’t limit what should be deserialized you can send data that shouldn’t be changed by something that comes from outside. You can change a password, change the balance, reset a history, change an identity, etc.
Depending on the system can cause the same damage as the SQL Injection, although something less worse is likely to occur.
It’s the old problem of having to validate all the information that comes from the application’s external source. It occurs when you do it by hand and when you don’t know how to use the framework right. You never have control over what from the outside, just accept what you are sure has no danger, block all the rest.
The Bind
help, but it does not solve everything. There are cases where the validation is not "can or cannot" receive the field, there is the way it can and the way it cannot.
Most of the applications you have out there are subject to that, including written by experienced people. I have seen course considered good that leaves this gap without being covered, it is taught to do the damage, but not how to combat it.
See more in Using client validation is sufficient?.