Mainnet-1.5.1

Mitigations
Use of Un-satisfied Authorizations in Self-addressed Actions and Transactions
This release contains subjective mitigations that will disallow any inline action or deferred transaction sent by a contract to itself that does not meet the following criteria:

For Self-Addressed Deferred Transactions
Only allow authorizations that
are satisfiable by eosio.code
AND meet the minimum permission of the action as linked by the actor present in the authorization
For Self-Addressed Inline Actions Sent From Direct Actions
Only allow authorizations that
are satisfiable by eosio.code OR are present in the parent action
AND meet the minimum permission of the action as linked by the actor present in the authorization
For Self-Addressed Inline Actions Sent From Recipient Handlers
Only allow authorizations that
are satisfiable by eosio.code
AND meet the minimum permission of the action as linked by the actor present in the authorization
Inline actions and deferred transactions sent to any other contract are unaffected by this change and remain secure.

Contract authors are advised to audit their code for instances where self-addressed inline actions and deferred transactions with improper authorizations may have slipped through as those contracts will no longer function properly.

For more information see the official block.one blog post

DEPRECATION NOTICE
The propagation of authorizations present on the parent action for self-addressed inline actions sent from direct actions is DEPRECATED IMMEDIATELY and will be removed during the first protocol upgrade. At that time only properly formed authorizations satisfiable using the eosio.code pattern will be allowed for any inline action or deferred transaction.

Contract Developers should take immediate action to refactor their contracts to not rely on these propagated authorizations.