Metamask Snap Audit Report for LiquidLink

Management Summary

LiquidLink contacted Sayfer Security in order to perform penetration testing on their Iota Metamask snap in July 2025.

Before assessing the above services, we held a kickoff meeting with the LiquidLink technical team and received an overview of the system and the goals for this research.

Over the research period of 2 weeks, we discovered 5 vulnerabilities in the system.

In conclusion, several fixes should be implemented following the report, but the system’s security posture is competent.

After a review by the Sayfer team, we certify that all the security issues mentioned in this report have been addressed by the LiquidLink team.

Risk Methodology

At Sayfer, we are committed to delivering the highest quality penetration testing to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the attack and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their business.

Risk is defined as follows:

Security Evaluation Methodology

Sayfer uses OWASP WSTG as our technical standard when reviewing web applications. After gaining a thorough understanding of the system we decided which OWASP tests are required to evaluate the system.

Security Assessment

After understanding and defining the scope, performing threat modeling, and evaluating the correct tests required in order to fully check the application for security flaws, we performed our security assessment.

Issue Table Description

Issue title

Description

Here we provide a brief description of the issue and how it formed, the steps we made to find or exploit it, along with proof of concept (if present), and how this issue can affect the product or its users.

Mitigation

Suggested resolving options for this issue and links to advised sites for further remediation.

Security Assessment Findings

Arbitrary Fullnode URL Injection

Description

By design, the snap gates admin functionality like setting the fullnode URL through the admin_setFullnodeUrl method, solely by checking the origin against hardcoded values, including https: /iotasnap.com. If an attacker is able to acquire that domain, they can host a malicious page that will pass assertAdminOrigin and invoke admin-only methods like admin_setFullnodeUrl.

• tsx:271-279

case 'admin_setFullnodeUrl': { 
  assertAdminOrigin(origin);
  const [validationError, params] = validate(
    request.params,
    SerializedAdminSetFullnodeUrl,
  );
  if (validationError = undefined) {
    throw InvalidParamsError.asSimpleError(validationError.message);
  }
                .
}

Because the fullnode URL is accepted without validation and user interaction, the attacker can then point the snap at arbitrary endpoints and manipulate all downstream behavior. Indeed, we found the whitelisted domain is not registered, and can be acquired by potential attackers.

Mitigation

We recommend ensuring that any admin origin domain is actually owned and provably controlled. Additionally even if the domain is trusted, it is suggested to inform the user with some dialog box, that his RPC URL was changed.

Lack of Input Validation for RPC Parameters

Description

The validation in most of the state changing methods is a no-op cast.

• ts:129-132

export const SerializedIotaSignPersonalMessageInput = (
  params: unknown,
): SerializedIotaSignPersonalMessageInput =>
  params as SerializedIotaSignPersonalMessageInput;

And validate<TData>( .) itself just calls the schema and checks structural correctness. There is no type enforcement, and no sanitization.

• ts:110-125

export function validate<TData>(
  params: unknown,
  schema: (params: unknown) => TData,
): [Error | undefined, TData] {
  try {
      / This is a simplified version since we don't know the exact
validation library
      / you might be using. If you're using zod, you would use
schema.parse(params)
      const result = schema(params);
      return [undefined, result];
  } catch (error) {
      return [
        error instanceof Error ? error : new Error('Validation failed'),
        {} as TData,
      ];
  }
}

Mitigation

Replace the current schema stubs with a real parser that strictly enforces required fields, types, allowed values, and rejects unexpected fields Additionally make sure that any subsequent usage assumes a properly validated shape, eliminating reliance on any where possible.

Transaction Mutability between Dry Run and Execution

Description

Dry runs are performed on the result of buildTransactionBlock(string, Transaction, string), which may mutate the transaction block (e.g. setting the sender) and produces canonical bytes (transactionBlockBytes).

• ts:142-144

if (!transactionBlock.getData().sender) {
  transactionBlock.setSender(sender);
}

However, after user confirmation, execution calls signAndExecuteTransaction(IotaClient, any, any, any) with the original input.transactionBlock instead of the built one. There is no binding or fingerprint comparison between what was dry-run and what is actually executed, so the executed transaction can diverge.

• tsx:255-2G3

const res = await signAndExecuteTransaction(
  client,
  input.transactionBlock as any,
  input.requestType,
  input.options,
);
const ret = res as any as IotaSignAndExecuteTransactionOutput;
return ret;
}

We recommend exactly executing the transaction that was dry-run: pass the built/mutated transaction block or its serialized bytes to signAndExecuteTransaction( .), or hash the dry-run bytes and compare against the execution serialization, aborting if they differ.

Mitigation

We recommend reconsidering the one‐time derived‐address write to initialization (Context.init()), and removing state writes from the handle() method so it remains truly read-only.

Misleading Estimated Gas Fees

Description

calcTotalGasFeesDec(  .) returns the literal string ‘0’ when

dryRunRes Yeffects YgasUsed is undefined, returning “no cost” rather than “estimate unavailable”. That value is then rendered in the confirmation dialog with no differentiation or warning when the underlying data was missing. The absence of gasUsed silently collapses into a zero-fee presentation.

• tsx:241-244

<Text>
  Estimated gas fees: *
  {calcTotalGasFeesDec(result.dryRunRes as any)} IOTA *
  /Text>

Mitigation

We recommend distinguishing between “zero fee” and “fee estimate unavailable”.

Inadequate Control Character Detection

Description

The code uses the regex /[в- -]/u to detect control characters and falls back to base 64 encoding when they appear. That pattern only covers a subset of C0 control characters and omits others (and does not address Unicode format characters like bidi overrides or zero-width characters) that can be abused for visual deception.

• tsx:52-55

if (/[в- -]/u.test(decodedMessage)) {
  decodedMessage = Buffer.from(input.message).toString('baseG4');
  info = ` *${origin} * is requesting to sign the following message
(baseG4 encoded):`;
}

Malicious actors could inject Unicode control characters like right-to-left override or zero-width spaces to manipulate how messages appear to users. Additionally, Certain control characters could break the MetaMask UI dialog rendering.

Mitigation

Replace the heuristic with robust detection, testing for all Unicode control and format characters using property escapes, like /\p{Cc}|\p{Cf}/u and explicitly handling known spoofing vectors like bidi overrides and zero-width characters.
Alternatively, if such characters will be found in the signed string – you could include the extra string to the message informing users that something seems to be wrong or malicious.