Cirrus Erase — Security

This page is the canonical public source for Cirrus Erase security contacts. If you've found a vulnerability, please report it privately via one of the channels below. Do not file a public GitHub issue for security reports.

Contacts

What to include in a report

• A clear description of the issue.
• The affected Cirrus version (in VERSION at the repo root, or visible at http://<lan-server>:8080/api/version on a deployed LAN Server).
• Steps to reproduce, with logs, captures, or screenshots where applicable.
• Your assessment of severity (we'll do our own assessment too).
• Credit preference: how you'd like to be named (or "anonymous").

What to expect

• Acknowledgement — within 5 business days.
• Initial assessment — within 10 business days.
• Coordinated disclosure — by mutual agreement, typically 90 days from acknowledgement.

Boot-chain integrity

Cirrus Erase ships a Microsoft-signed UEFI shim signed under the "Cirrus Erase" vendor identity. The shim signature can be inspected with sbverify or pesign.

If you find a binary attributed to Cirrus Erase that fails signature verification against the Microsoft UEFI CA, report it via the primary contact above — this would indicate either a key compromise or a binary-substitution attack, both of which we treat as the highest severity.

For the record:

• The Cirrus Erase shim never invokes shim's MOK-enrolment pathway. It never writes to a target machine's UEFI NVRAM. If you observe MOK-enrolment behaviour from a Cirrus Erase boot session, that is a defect.
• The ADISA-certified Erase .so is published with a known SHA-256. Reports of .so substitution or modification at runtime are highest priority.

Published advisories

Past security advisories are listed at /advisories.