This bears some resemblance to the SQL Injection , but now because of an automation that a framework provides to slow down the coding work. Usually occurs with MVC and ORM.
What usually occurs is that what comes from the URL is deserialized to an object that is persisted later in the database. If you do not limit what should be deserialized it is possible to send data that should not 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, it may cause the same damage as SQL Injection, although something less is likely to occur.
It's the old problem of validating all information that comes from outside the application. It occurs when done in the hand and occurs when you do not know how to use the framework right. You never have control over what's out, just accept what you're sure has no danger, block everything else.
Bind
helps, but does not solve everything. There are cases where validation is not "can or can not" receive the field, it has the way it can and the way it can not.
Most of the applications out there are subject to this, even written by experienced people. I have seen course taken as good that leaves this gap without being covered, it is taught to do the damage, but not how to fight it.
See more in Is using validation via client enough? .