The Monero Research Lab is a team of voluntary researchers, scientists and academics that did analyse Monero and its predecessor CryptoNote in the past, explaining both past attacks and possible privacy issues in the current network. Their research is mostly funded by donations from the Monero community and is publicly available.

In the following segment I will list every security issue they found and their implemented or proposed solution. Elaborations are my comments but are mostly based on the research results.

TL;DR

Seven possible attack vectors

Six solutions have been implemented

One issue is not yet resolved

If an attacker owns many transactions and you use solely his outputs as mixins, he is able to deobfuscate the ring signature. He could spam the network with transactions to increase the probability of becoming a mixin.

Solution: Enforced minimum mixin of 2 will reduce the share of evil outputs over time

Status: Implemented

Elaboration

Fees and a possible deflation make this attack rather expensive for the excessive amounts the attacker would need to buy, hold and move: "If Burns controls half of all outputs, then 12.5% of all new transactions will have a ring signature composed entirely of his outputs"

Accidental deobfuscations (mixin = 0) can be prevented by enforcing a protocol level minimum mixin

With a protocol level minimum mixin of 2 and the resulting 12.5% chance of deobfuscating a transaction, the share of the malicious outputs gets reduced with every new transaction on the network, effectively "repairing" itself as long as the attacker does not keep on producing outputs

On 4 September 2014, an unusual and novel attack was executed against the Monero cryptocurrency network. This attack partitioned the network into two distinct subsets which refused to accept the legitimacy of the other subset.

Solution

On [...] the same date as the attack, the first solution to the exploit was publicly announced by Rafal Freeman [...] The Monero development team released patch 0.8.8.3 on 6 September 2014 to [...] allow miners to identify the A side of the network [...] and to identify foreign nodes with the B-side version of block 202612

Status: Implemented

Elaboration

A bug in the fresh fork of the poorly documented Bytecoin implementation caused this issue that was fixed temporarily on the same day and permanently two days later

The attack made different nodes not recognize each other as correctly working, splitting the nodes temporarily into two parallel blockchains and effectively doubling the amount of funds per person

One may have reasonably assumed that the original CryptoNote developers would have implemented a standardized denomination requirement for all transaction outputs, but [...] the protocol does not disallow any strange denominations [...] Hence, no mix-ins are possible

Solution: RingCT hides the amounts of transactions, making denominations useless and removing dust

Status: Implemented

An observer cannot distinguish which transaction output [...] is the output actually being spent [...] However, [...] an attacker may model the cumulative probability that the output has already been spent as an increasing function of time [...] Hence, [...] the youngest output used to fashion the ring signature is the most likely output to be the genuine output being spent

Solution: No solution in sight ( discussion for a solution can be found here )

Elaboration

When an exchange rate is experiencing a [...] inflation, rational users are more likely to spend their transaction outputs [...] When an exchange rate is experiencing a [...] deflation, rational users are more likely to hoard [...] Hence, the distribution of transaction output ages will at least vary over time, and, presuming any proportion of users are rational will certainly depend sensitively on the economic performance of the currency. It is unwise to design security recommendations around the economic performance of our protocol.

Note: This issue is currently the biggest issue of Monero privacy and was subject to another scientific paper, which can be found here. This research is under criticism for not clarifying the ties to the ZCash Foundation well enough.

an observer may conclude that the outputs stemming from a common root transaction are more likely to belong to the true signer of the transaction

Solution: RingCT will prevent denominations and therefore reduce the probability of outputs stemming from the same transaction

Status: Implemented

if a set of distinct transactions has some common data (such as a common block height) and if all transactions in this set use mix-ins with some other common data, then it is likely that these transactions are related by a common user

Solution: RingCT reduces the amount of shared data

Status: Implemented

One possible attack against the original CryptoNote or ring-coin protocol is blockchain analysis based on the amounts sent in a given transaction it requires a given [...] ring signature with other pubkeys having the same amount. For less common amounts, this means there may be a smaller number of potential pairs

Solution: RingCT. MRL-0005 is actually all about how it works.

Status: Implemented