Security fixes are applied exclusively to the latest official release. To ensure your system remains secure, always run the most recent release tag.

Please check the project's Official Releases Page to confirm you are running the latest version.

Forks should also include in the Release tags the SHA256 certificates of their project, so users can easily verify the SHA256 certificates. Forks should not just copy-paste the SHA256 file from the main project and upload it to Releases.

To ensure Responsible Vulnerability Disclosure in forks, forks should enable Private Vulnerability Report via going to Security and quality and enable Private Vulnerability Report.

We strongly advocate for Responsible Vulnerability Disclosure. If you discover a security flaw in this project, do not open a public issue, pull request, or public discussion, unless you're reporting in a fork that has disabled Private Vulnerability Reporting for whatever reason.

1. Navigate to the Security tab of this repository.
2. Click Report a vulnerability to initiate a Private Vulnerability Report.
3. Provide full reproduction steps and a Safe Proof of Concept (PoC).
   • A safe PoC must trigger harmless, verifiable behavior (such as writing a benign text log or creating a temporary desktop file) without deploying or executing malicious payloads.

If you want to report a vulnerability in a fork that has disabled Private Vulnerability Reporting - open a Bug Report instead, under Mac model, select Not applicable, under macOS version, write a dash (-) and under Issue type, select Security vulnerability - inside the fork itself, not in the main project.

This project intentionally relaxes specific OS security controls to enable extended hardware compatibility. The following items are fundamental to the project's design and are strictly out-of-scope:

• System Integrity Protection (SIP) Modifications: Disabling or lowering SIP configurations necessary to inject custom kernel extensions.
• Apple Mobile File Integrity (AMFI) Relaxations: Disabling AMFI checks required to execute patched runtime drivers.
• Boot Security & Library Validation Overrides: System policy adjustments required to bypass native platform hardware restrictions.
• Exception: if an attacker could trick into injecting policies for T2 Macs on non-T2 systems to intentionally lower security or vice versa, then this is not out out of scope and should be reported immediately.

Reports concerning these deliberate bypasses will be closed as By Design.

Forks should not typosquat their names (e.g ОpenCore-Legacy-Patcher-T2 with cyrilic O or OCLP-T2). If users detect such forks, they should report immediately to the maintainer via Issues. This is an example of typosquatting:

Also, forks shouldn't spoof their version as if it were newer than it is without disclosing that their project is not affiliated with Albert Müller or its contributors. This is an example of version spoofing:

To protect yourself against homoglyph attacks (e.g., lookalike repository names using Cyrillic/Unicode characters) and fake version tagging, always verify binary integrity:

1. Obtain builds only from official repository tags.
2. Verify downloaded release archives against the published SHA-256 checksums: shasum -a 256 .zip

This is an example of typosquatting: