As Shipyard Winds Down, IPFS Phishing Enters a New Phase

The central actor behind decentralization

IPFS was originally created by Protocol Labs’ founder Juan Benet in 2014. Since then, Protocol Labs has formed the backbone of IPFS use across the web, creating and maintaining tools for decentralized file systems.  

They also hosted the most popular public IPFS gateways that users would go through to access the service, ipfs.io and dweb.link. In 2024, responsibility for these gateways was taken on by an offshoot of Protocol Labs, the open-source collective Interplanetary Shipyard, also known as just “Shipyard.” 

While Protocol Labs remained a key funder of this work, Shipyard took steps to further decentralize the IPFS ecosystem. This effort included the creation of inbrowser.link, a gateway using a browser service worker API to fetch content with the browser acting as its own local IPFS gateway. 

While these efforts have helped reduce reliance on centralized IPFS gateways, it didn’t branch out much from reliance on Protocol Labs’ ecosystem. In August 2026, it was announced that Protocol Labs would not be renewing their funding of Shipyard, effectively ending the project. 

In a sea of files, there’s plenty of phish 

The ability to abuse decentralized services for delivery of malicious content is well‑known.  

Gateway URLs can allow phishing sites to sit behind links that look like trusted domains. Takedown requires additional effort as the content’s hosting and distribution are decoupled, allowing content to reappear at the same content identifier (CID). 

Netcraft tracks IPFS fronting used by the phishing sites we take down. So far in 2026, Shipyard‑maintained gateways account for 84% of this. 

While inbrowser.link appears as the third most popular IPFS fronting gateway, it is worth noting that ipfs.io and dweb.link addresses began redirecting to inbrowser.link in May 2026. This transition has allowed more decentralization in the sense that IPFS gateways are local through the service worker used in the browser. However, this is still reliant on inbrowser.link as the source of the service worker code and most of this ecosystem still relies on services run by Shipyard. 

Example of a phishing site using IPFS fronting and targeting food stamps users. 

Shipbreaking and what comes next 

As Shipyard winds down its operations, responsibility for the gateways will return to Protocol Labs. However, they made it clear that their stewardship model will change significantly and have made no guaranteed of continued long-term support for the service worker gateway supplied through inbrowser.link. Additionally, many of the nodes used in peer routing and bootstrap nodes were maintained by Shipyard, which will stop running them on Sept. 30. The loss of Shipyard’s public infrastructure used in IPFS will affect the ability of in-browser service worker gateways when hardcoded bootstrap nodes disappear and infrastructure is not reliably available for routing. 

While the ecosystem adapts and other gateways get a chance at popularity, threat actors using IPFS fronting will likely see a mix of opportunities and infrastructure loss. Protocol Labs is expected to continue maintaining the Bad Bits Denylist, a denylist used for malicious content identification. Netcraft is in contact with someone involved in the Bad Bits Denylist pipeline who plans to modernize it, with further information coming. As other Protocol Labs services wind down, the IPFS ecosystem is expected to shift toward other gateway providers who may not have the same content policy maturity and may choose not to enforce the Bad Bits Denylist. This creates the opportunity for threat actors to test other gateway providers with trusted domains that are expected to become more familiar. 

Example of Protocol Labs’ Bad Bits Denylist being applied. 

There is also likely to be a short-term reduction in the volume of data that can be handled by IPFS as a fronting service. The disruption to IPFS ecosystem reliability will likely be a hindrance to phishing campaigns that expect this as a core path to accessing their malicious sites. 

For users, security teams, and companies looking to protect their brands, they may expect to take on more responsibility for the proactive management of IPFS risk. Through using or maintaining active deny lists, proactive content takedown, and monitoring, some of these risks can be mitigated. However, this is expected to be a volatile landscape in the near future, and risk should not be considered settled until new gateway solutions have stabilized their market shares and have known content moderation policies.