# May 2026 Estate Fingerprint Collision Vulnerability Post-Mortem

**URL:** <https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272>\
**Category:** Uncategorized\
**Created:** [May 21, 2026, 11:22am UTC](https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272 "2026-05-21T11:22:46Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nacho](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.decentraland.org/nacho/32/29346_2.png) [@Nacho](https://forum.decentraland.org/u/Nacho)\
**Post date:** [May 21, 2026, 11:22am UTC](https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272/1 "2026-05-21T11:22:46Z")

</div>

**Incident Date:** 4/27/2026

**Resolution Date:** 5/20/2026 - [Upgrade transaction](https://etherscan.io/tx/0x4167346bcde535cfca9c2c0fb107eedcd63cafaf94e7535e9174b57192d47046)

**TLDR** : Your LANDs, Estates, and all assets are safe. The marketplace is fully operational

On April 27, 2026, we received a vulnerability report on Immunefi describing a flaw in `EstateRegistry.getFingerprint` that allowed an Estate’s contents to be silently swapped while keeping the same on-chain fingerprint. In practice, a seller could list an Estate on the marketplace with a given set of LANDs and, before the buyer’s order executed, substitute a different set of LANDs without invalidating the order’s signature.

**Funds:** No user funds were lost. The vulnerability required an active marketplace order and a coordinated swap operation; no exploitation has been observed on-chain.

### Context

The legacy fingerprint algorithm had a mathematical property that, beyond roughly **256 LANDs** , made it possible to swap a subset of LANDs in an Estate for a different subset while keeping the fingerprint unchanged. In practical terms, **any Estate larger than ~256 LANDs was at structural risk** of an undetectable contents swap. Smaller Estates were far less exposed, but to leave a comfortable safety margin we drew the line much earlier: the patch treats **any Estate with 19 or more LANDs** as requiring the new fingerprint. For Estates below that threshold, finding a malicious swap is computationally comparable to **brute-forcing a private key** — essentially impossible with any known technology.

Because the issue stemmed from how the original fingerprint combined LAND identifiers, we determined that a backwards-compatible fix was possible: introduce a new fingerprint algorithm, gate verification behind it, and keep the legacy one available only for the small Estates and time window where it is still safe — avoiding any disruption to Estates already listed on the marketplace.

### **Remediation**

The fix introduces a new `getFingerprintV2` function that hashes the Estate contents with `keccak256(abi.encode(...))`, which is non-linear and bound to the length and order of the LAND array — eliminating the collision class entirely.

The existing `getFingerprint` function is preserved (now marked `UNSAFE` in the contract documentation) so read-only integrations continue to work. The on-chain `verifyFingerprint` function was updated to:

- Always accept the new v2 fingerprint, regardless of Estate size or time.

- Accept the legacy v1 fingerprint only as a transitional fallback, and only for Estates with fewer than 19 LANDs and only until **2026-11-26 15:00 UTC**.

This dual-mode window gives marketplace integrations a controlled migration path: new orders can be signed with v2 immediately, while orders already signed under v1 remain verifiable until the cutoff. After the cutoff, only v2 is accepted.

The SAB sent the [upgrade transaction on May 21, 2026](https://etherscan.io/tx/0x4167346bcde535cfca9c2c0fb107eedcd63cafaf94e7535e9174b57192d47046).

### Current Status

The patched `EstateRegistry` implementation has been deployed on **Ethereum** , and all first-party integrations (dApps, indexers, and signing helpers) have been updated to emit v2 fingerprints by default. The legacy v1 fallback remains active for in-flight orders and will be disabled automatically at the cutoff timestamp on **2026-11-26 15:00 UTC**.

**Impact on existing orders**

> _Your LANDs, Estates and every assets are safe_

- **20 active orders** involve Estates with **more than 18 LANDs**. These cannot be executed against the new contract and must be re-listed by their owners using the updated marketplace flow, which signs against the v2 fingerprint. Affected owners will see a prompt in the marketplace UI guiding them through the re-listing process:

- Orders covering Estates with **fewer than 19 LANDs** can still be executed safely. These sit well below the size where the original vulnerability becomes exploitable, and `verifyFingerprint` continues to accept their existing v1 fingerprints during the transition window. **However** , this is temporary: on 2026-11-26 15:00 UTC every v1-signed order or rental becomes invalid on-chain, regardless of Estate size. Owners should re-list them under the new flow before the cutoff to avoid losing their listings.

- **Rentals** are not impacted

- ThirdParty Marketplaces such as Opensea are **not** impacted.

### Acknowledgment

We thank the whitehat researcher for the responsible disclosure and the constructive collaboration during remediation and research, which allowed us to deploy a backwards-compatible fix with no disruption to active marketplace users.

---

<div class="post-metadata">

**Author:** ![3Point1Four](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.decentraland.org/3point1four/32/19627_2.png) [@3Point1Four](https://forum.decentraland.org/u/3Point1Four)\
**Post date:** [May 25, 2026, 3:52pm UTC](https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272/2 "2026-05-25T15:52:04Z")

</div>

Hi may I know if this is rectified? It seems that its still happening for newly minted estates larger than 20 lands

---

<div class="post-metadata">

**Author:** ![3Point1Four](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.decentraland.org/3point1four/32/19627_2.png) [@3Point1Four](https://forum.decentraland.org/u/3Point1Four)\
**Post date:** [June 29, 2026, 4:56am UTC](https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272/3 "2026-06-29T04:56:41Z")

</div>

Hi @Nacho nudging you again regarding this issue. I’ve just minted a new estate but people can’t purchase the estate. Same goes for other listings that were created after the update that happened in May.  
This is the link:

> **[Decentraland Marketplace | Wearables, LAND, and NAMEs](https://decentraland.org/marketplace/contracts/0x959e104e1a4db6317fa58f8295f586e1a978c297/tokens/6466)**
>
> Browse Wearables, Emotes, LAND, and NAMEs in the Decentraland Marketplace. Customize your avatar, explore creations, and find items from the community.

 ![Decentraland Marketplace _ Wearables, LAND, and NAMEs - Google Chrome 29_6_2026 12_49_34 pm](https://europe1.discourse-cdn.com/flex013/uploads/decentraland/original/3X/f/e/fea468ac88edc3971c30dc127a30cfcce414c5c7.png)

---

<div class="post-metadata">

**Author:** ![Nacho](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.decentraland.org/nacho/32/29346_2.png) [@Nacho](https://forum.decentraland.org/u/Nacho)\
**Post date:** [July 3, 2026, 12:23pm UTC](https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272/4 "2026-07-03T12:23:36Z")

</div>

What do you mean by `can't purchase`? Is it because of the message in the UI or because someone tried to buy it?

For the UI message, it should be fixed now. Also, I have simulated buying it, and it worked.

Can you confirm?

---

<div class="post-metadata">

**Author:** ![3Point1Four](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.decentraland.org/3point1four/32/19627_2.png) [@3Point1Four](https://forum.decentraland.org/u/3Point1Four)\
**Post date:** [July 3, 2026, 3:33pm UTC](https://forum.decentraland.org/t/may-2026-estate-fingerprint-collision-vulnerability-post-mortem/25272/5 "2026-07-03T15:33:23Z")

</div>

Yes its been rectified after enquiring in Discord. Now all is working
