This year's theme is upgradable contracts, or, more specifically, upgrade mechanisms.
In order to fix bugs in smart contracts, it is often necessary to perform upgrades. The problem with upgrades is that there is no feasible automatic mechanism to control that the new code still does what the old code intended to do. Because of that, upgrade mechanisms are often designed such that a single account has the ability to change the code arbitrarily. Since a smart contract in which a single account is authorized to arbitrarily change its implementation defeats the idea of decentralization, we would like to use this contest to find mechanisms that are better suited, be it via an opt-out mechanism, a way to split the contract or whatever else you can come up with. At the same time, this mechanism has to have a flaw or backdoor that is not easy to discover so that in the end, there is still a single account in control, even if it does not seem like it.
To keep submissions reasonably sized, the contract that is actually to be upgraded should be very small, e.g. an ERC20 contract or a simple registry. Note that the flaw should be in the upgrade mechanism, not in the main contract - you do not have to come up with a reason to actually upgrade the contract, but a little “story” around the hack is always nice, too.