# Content from other nodes is checked against a record they can't forge

> Gateways and browsers trusted a peer's own description of the content it sent. Every piece from a peer is now checked against a digest recorded when the site was uploaded, and anything that fails comes from the gateway instead.

Date: October 1, 2026 · Type: Security · Products: CDN, Edge Node

Source: https://changelog.evolvingedge.ai/2026-10-01-peer-content-checked-against-a-digest/

When a gateway or a visitor's browser fetches part of a site from another node, it has to know the bytes are the ones you uploaded. Until now, the check compared them against a description supplied by the node that sent them, so a node could send altered content along with a description that matched it.

**No incident of this has occurred. This is a proactive security fix.**

When you upload a site, the control plane now records a digest of every stored block. Gateways and browsers check each block from another node against that record, which comes from the control plane or the gateway, never from a peer. A block that doesn't match is thrown away and fetched from the gateway instead. Browsers also no longer accept a whole file from a node at all, only blocks they can check one by one.

## What you need to do

Nothing for most sites. Sites deployed from the portal at Level 0 or Level 2, and Level 0 sites deployed with ee-cdn-cli, carry the digest already.

**Level 1 sites deployed from the portal** carry the digest only if they were deployed on or after 26 October. A Level 1 site deployed from the portal before then has none, so its content comes from the gateway only, never from other nodes, until you deploy it again. [The portal deploys entry](https://changelog.evolvingedge.ai/2026/10/portal-encrypted-deploys-work-again/) has more.

**Level 1 sites deployed with ee-cdn-cli** don't send the digest yet. Until a CLI release that does, their content comes from the gateway only, never from other nodes. Nothing breaks.