This year's theme is upgradable contracts, or, more specifically, upgrade mechanisms.
Upgrades are a frequently used practice and are often necessary, e.g. to fix bugs in smart contracts. The problem with upgrades lays in the fact that, most times, users aren’t presented with the upgrade beforehand and no consent is needed from the users to execute it. Upgrade mechanisms are often designed such that a single account has the ability to change the code arbitrarily. However, a smart contract in which a single account is authorised to arbitrarily change its implementation defeats the idea of decentralization.
Come up with an upgrade mechanism that seems fair and safe (e.g. by implementing an opt-out mechanism or a way to split the contract) but has a flaw or backdoor. The backdoor should be hard to discover and, in the best case, results in a single account having full 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.