Late Taffy Tarantula Vulnerability Signature Threshold Bypass Explained

Hey guys! Let's dive deep into a critical vulnerability dubbed "Late Taffy Tarantula" found in the Consensus contract. This flaw allows a malicious actor to bypass the signature threshold, potentially wreaking havoc on the system. We're talking unauthorized deposits, redemptions, and even manipulation of user shares! So, buckle up as we break down the issue, its root cause, how an attacker could exploit it, and the steps we can take to mitigate it. This falls under the sherlock-audit and specifically relates to the 2025-07-mellow-flexible-vaults-judging discussion category.

Summary

The signature threshold bypass vulnerability in the checkSignatures function of the Consensus contract is a serious issue. Due to the absence of a check for duplicate signers, a malicious actor can reuse their own signature multiple times. This tricks the system into thinking the required signature threshold has been met. Consequently, this allows unauthorized actions like deposits or redemptions to be executed. It's like showing the same ID card multiple times to get past security – sneaky, right?

Root Cause

The heart of the problem lies in the checkSignatures function. It doesn't verify the uniqueness of signers. The function loops through the provided signatures but never checks if a signer has already been included. This omission means a single, compromised signer can submit multiple valid signatures associated with their address. By doing this, they can effectively bypass the intended consensus mechanism. Think of it like a loophole – and we're here to close it!

 function checkSignatures(bytes32 orderHash, Signature[] calldata signatures) public view returns (bool) {

 for (uint256 i = 0; i < signatures.length; i++) {
 address signer = signatures[i].signer;
 (bool exists, uint256 signatureTypeValue) = $.signers.tryGet(signer);
 if (!exists) {
 return false;
 }
 ...
 }

As you can see in the code snippet, there's no logic in place to prevent a signer from appearing multiple times within the signatures array. This is the crucial flaw that attackers can exploit.

Internal Pre-conditions

For this vulnerability to be exploitable, the attacker must be a valid signer recognized by the consensus mechanism. They need to be one of the authorized parties whose signatures are considered valid.

External Pre-conditions

There are no specific external preconditions besides the inherent vulnerability in the contract's logic. The exploit hinges solely on the lack of duplicate signer checks within the checkSignatures function.

Attack Path

Let's walk through how an attacker would pull this off, step by step:

1. Craft Orders with Favorable Prices: The attacker prepares Order structs with intentionally skewed ratios. These ratios manipulate the price bounds for their benefit:

   • Deposits: The attacker sets a low ordered value and a high requested value (e.g., price +5%). This allows them to mint extra shares during the deposit.
   • Redeems: Conversely, they set a high ordered value and a low requested value (e.g., price -5%). This results in receiving more assets per share burned during redemption.

   The key here is that these skewed prices stay within the oracle’s maximum deviation threshold. This prevents any invalid price checks from being triggered. It’s like walking a tightrope just within the allowed limits.

2. Reuse Signatures to Meet Threshold: Because the contract doesn't check for duplicate signers, the attacker simply reuses their own signature multiple times within the signatures array. This satisfies the required signature threshold, even though it's just a single entity providing all the approvals. It's like voting multiple times in an election – but in this case, it works due to the missing check.

3. Profit Through Price Manipulation: By manipulating the price bounds on deposits and redeems (within the small deviations tolerated by the oracle), the attacker can extract profit. They essentially game the system by exploiting the skewed prices and the bypassed signature threshold.

Impact

The impact of this vulnerability is significant. A malicious authorized signer can exploit the system to their advantage. The combination of permissive oracle deviation bounds (e.g., ±5%) and the lack of duplicate signer detection creates a perfect storm for abuse.

Specifically, the attacker can:

• Burn any User's Shares: By crafting malicious orders, the attacker can force the burning of shares belonging to other users, essentially stealing their stake in the system.
• Redeem Tokens at Favorable Rates: They can redeem tokens at advantageous rates due to the skewed prices, siphoning off assets from the system.

This can lead to substantial financial losses for users and a significant erosion of trust in the platform.

PoC

Here’s a Proof of Concept (PoC) written in Solidity to demonstrate the vulnerability. This test case highlights how easily the checkSignatures function can be bypassed with duplicate signatures.

 // flexible-vaults/test/unit/permissions/Consensus.t.sol

 function testDoubleSignatureWorks() public {
 Consensus consensus = _createConsensus();

 uint256 pk = uint256(keccak256("private key 1"));
 address signer = vm.addr(pk);

 vm.prank(admin);
 consensus.addSigner(signer, 1, IConsensus.SignatureType.EIP712);
 vm.prank(admin);

 consensus.addSigner(signer2, 2, IConsensus.SignatureType.EIP1271);

 bytes memory sig = _sign(dummyHash, pk);
 IConsensus.Signature[] memory signatures = new IConsensus.Signature[](
 2
 );
 assertEq(consensus.threshold(), 2);

 signatures[0] = IConsensus.Signature({signer: signer, signature: sig});
 signatures[1] = IConsensus.Signature({signer: signer, signature: sig});

 assertTrue(consensus.checkSignatures(dummyHash, signatures));
 }

This test case clearly shows that using the same signer's signature twice allows the checkSignatures function to return true, effectively bypassing the intended threshold. It's a critical demonstration of the vulnerability in action.

Mitigation

The solution to this vulnerability is straightforward: enforce signer uniqueness within the checkSignatures function. This can be achieved by adding a check to ensure that each signer appears only once in the signatures array.

Here’s a high-level concept of how this mitigation could be implemented:

1. Maintain a Set of Signers: Inside the checkSignatures function, create a data structure (like a mapping or a Set) to track the signers who have already been processed.
2. Check for Duplicates: Before processing a signature, check if the signer's address is already present in the set. If it is, reject the signature (or the entire transaction). If not, add the signer to the set and proceed with signature verification.

By implementing this simple check, we can effectively prevent the duplicate signature bypass and ensure the integrity of the consensus mechanism. This is a crucial step in securing the system against malicious actors.

In conclusion, the “Late Taffy Tarantula” vulnerability highlights the importance of thorough security audits and the need to consider even seemingly minor omissions in code. By understanding the root cause, attack path, and potential impact, we can take the necessary steps to mitigate the risk and protect the system from exploitation. Stay vigilant, guys, and keep those smart contracts secure!