Two authorities getting conflated into one
The confused deputy problem describes a component — a program, a service, a script — that holds legitimate authority to perform some action, and also accepts instructions from a caller that shouldn't have that authority itself. If the component executes the caller's instruction using its own broad authority rather than the caller's narrower one, the caller has effectively borrowed permissions it was never granted, without anyone having to steal a credential.
The classic version involves a shared, ambient authority — a component that acts with its own privileges by default, on whatever it's told to do, without distinguishing whose request it's fulfilling. Fixing it isn't about better validation of the instruction's contents; it's about making sure the component's authority is scoped to what the actual requester should be allowed, not to what the component itself happens to hold.
Why this keeps reappearing in new systems
The pattern shows up anywhere a trusted intermediary sits between a caller and a resource: a service that fetches URLs on a user's behalf, a script that writes files using its own elevated account, an automation tool that runs with more permission than the person who triggered it. Each new integration point is a fresh opportunity to reintroduce the same structural mistake, which is why naming the pattern explicitly is more useful than trying to patch each instance individually.