user3347: The Lightning Paper v0.5.9.2 says that CSV "would permit further
abilities, including allowing a stop-gap solution before a more permanent
solution for resolving transaction malleability. A future version of this
paper will include proposed solutions."
This means that Thunder is still vulnerable to malleability attacks since it relies on CSV as a solution.
Since the Thunder readme does not mention malleability fixes as a TODO point, I guess the Thunder authors considers it fixed. 
The cited Lightning draft is from January.

user208: CSV is not a stop-gap solution. Before you can say that, you first need to define what the problem is.
CSV solves the problem that you can't use CLTV in contracts that need a spending delay where the output itself will not be broadcast for an unknown amount of time. This is a very abstract problem, but it does occur as a primitive inside more complex constructions.
However, the current Thunder implementation uses a stop-gap solution to transaction malleability, which just happens to rely on CSV.

3347: <p>The <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow">Lightning Paper</a> v0.5.9.2 says that CSV "would permit further
abilities, including allowing a stop-gap solution before a more permanent
solution for resolving transaction malleability. A future version of this
paper will include proposed solutions."</p>

<p>This means that Thunder is still vulnerable to malleability attacks since it relies on CSV as a solution.</p>

<p>Since <a href="https://github.com/blockchain/thunder/blob/fc84b8de9378a9f5086c8fb6f198d2857766e167/README.md#feature-list" rel="nofollow">the Thunder readme</a> does not mention malleability fixes as a TODO point, I guess the Thunder authors considers it fixed. </p>

<p>The cited Lightning draft is from January.</p>
 208: <p>CSV is not a stop-gap solution. Before you can say that, you first need to define what the problem is.</p>

<p>CSV solves the problem that you can't use CLTV in contracts that need a spending delay where the output itself will not be broadcast for an unknown amount of time. This is a very abstract problem, but it does occur as a primitive inside more complex constructions.</p>

<p>However, the current Thunder implementation uses a stop-gap solution to transaction malleability, which just happens to rely on CSV.</p>
