Cloudflare reports a routing-policy change on a Miami router unintentionally advertised routes to peers and transit providers.
Cloudflare · inspect the source ↗INCIDENT BRIEF / SERVICE OUTAGE
Cloudflare IPv6 route leak: inspect policy meaning after removing a condition
Removing a restrictive condition can widen a policy even when the change looks like cleanup. Review a policy’s evaluated result for representative allowed and denied cases. The same reasoning applies to data access filters and supplier-managed routing changes, without assuming identical technical mechanisms. Use the preserved provider account below to distinguish reported facts from the proposed review exercise.
01 / SOURCE-ATTRIBUTED REPORTING
What the evidence establishes.
The report explains that removing a prefix list left a policy that accepted internal routes too broadly.
Cloudflare · inspect the source ↗Its timeline records manual reversion and paused automation at 20:50 UTC.
Cloudflare · inspect the source ↗02 / KEEP THE SEQUENCE
A dated record.
Reported incident date
Cloudflare reports a routing-policy change on a Miami router unintentionally advertised routes to peers and transit providers.
Source reference ↗
Dates and time zones follow the cited report where specified. A report date is distinct from the incident date and from our review.
03 / GOVERNATLAS EDITORIAL ANALYSIS
Make the lesson useful.
These are proposed review and trial activities inspired by the reported event. They are not completed tests or claims that a particular control guarantees prevention.
Review the resulting permission, not just the deleted line
Removing a restrictive condition can widen a policy even when the change looks like cleanup. Review a policy’s evaluated result for representative allowed and denied cases. The same reasoning applies to data access filters and supplier-managed routing changes, without assuming identical technical mechanisms.
BRING THIS INTO YOUR REVIEW
Open the working guide ↗For a proposed policy change, enumerate accepted and rejected examples before and after. Include an empty condition and an internal-only item, preserve the evaluated outputs and define rollback authority before applying it.
FROM READING TO A REVIEW YOU CAN OWN
What will you examine next?
A reported failure is a reason to ask a precise question about your own service. It does not establish that your configuration shares the same weakness. Start with the workflow, deployment and dependencies you can identify, then decide which proposed activity is relevant.
For each relevant lesson, name an accountable role, describe the evidence you would request and define an authorized trial before performing it. Keep “not checked” distinct from a recorded observation. If a check reveals a gap, retain its scope and next action rather than converting the observation into a supplier-wide verdict.
Use this portable record in a review, renewal discussion or continuity exercise. A material configuration change, a revised incident account or the completion of an action can trigger your next review. Your entries remain your working notes; publication evidence and your own acceptance decision are separate records.
Use non-sensitive roles and evidence references. Entries stay in this open page and reset on reload; download before leaving. This tool performs no tests and produces no readiness score.
1 unassigned owner · 1 activity not checked
Define a safe, measurable rehearsal
Record the normal result before changing anything. Agree an authorized test boundary, an observable stop condition and who can stop the exercise. Check restored configuration and unfinished work separately. These entries are your plan, not permission to test a service.
04 / LEAVE UNCERTAINTY VISIBLE
What this record does not establish.
This is an attributed review of a preserved provider account, not an independent reconstruction or a finding about current reliability.
Customer-specific losses, exposure and recovery outcomes are not established by these passages. The proposed exercise has not been performed by GovernAtlas.
Geography: The report describes service scope below. No single affected-user location is inferred from infrastructure, company headquarters or routing origin.
05 / THE EVIDENCE RECORD
Sources & editorial review.
Route leak incident on January 22, 2026 ↗
Cloudflare · captured 2026-10-17 (UTC)
Inspect preserved provenance
- Source
- 1b8ad963-781b-489b-8f73-81d35df5d24d
- Observation
- 3e3ef95d-1296-42f2-b736-75a804df776d
- SHA-256
- b4d7dc60277a3130f20c4bb6a7c999adb4a58b8491a6f594b14df49b86d92d05
Reporting and proposed methods by GovernAtlas editorial. Published review: 2026-10-17 (UTC). Revision 1. Preserved source bytes identify the material reviewed; they do not independently verify the provider’s account.
Submit a correction with supporting evidence ↗