Yes. CISA added CVE-2021-27562 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Arm Trusted Firmware contains an out-of-bounds write vulnerability allowing the non-secure (NS) world to trigger a system halt, overwrite secure data, or print out secure data when calling secure functions under the non-secure processing environment (NSPE) handler mode.
What “being exploited in the wild” means for this CVE
For this vulnerability, the practical question is not whether the flaw exists, but whether active exploitation has already been observed by a trusted source. That matters because CISA’s KEV catalogue is intended to distinguish theoretical exposure from vulnerabilities that merit urgent operational attention, especially when the vulnerable component sits in firmware or trusted execution paths.
Once a CVE is in KEV, the issue moves from routine vulnerability tracking to exposure management. A firmware-level flaw can have a broader blast radius than an application bug because it may affect secure-world behaviour, platform integrity, and the reliability of controls that sit above the hardware boundary.
Why Arm Trusted Firmware out-of-bounds write is operationally serious
The cited flaw is an out-of-bounds write in Arm Trusted Firmware, which means the non-secure side of the system can influence a trusted execution boundary in ways that should not be possible. That is significant because the secure monitor and trusted firmware often mediate access to protected data, platform services, and security state.
In practice, a vulnerability of this type can produce more than a crash. Depending on how the vulnerable code path is reached, it can halt the system, alter secure data, or expose sensitive information from the secure world. That combination makes it relevant to confidentiality, integrity, and availability at the same time.
For readers who want the broader firmware-security context, Embedded Device Security Guide covers the defensive issues that commonly surround trusted firmware, secure boot, rollback resistance, and interface hardening.
What to check before you assume you are safe
The first verification step is whether any platform in your estate actually uses the affected trusted firmware path, especially on embedded, mobile, or appliance-style systems where security components are bundled into firmware images. If you do not have a reliable hardware and firmware inventory, you do not have a reliable answer.
The second check is whether the vulnerable firmware is present in images that are deployed, dormant in update packages, or inherited through third-party platform builds. Firmware exposure is often missed because it sits below the usual endpoint and application visibility layers, so asset discovery and version provenance matter as much as patch status.
For vulnerability triage and exposure confirmation, use the authoritative record first: CVE Program for the identifier and NIST National Vulnerability Database for structured vulnerability data. For exploitation status and required action, use the CISA Known Exploited Vulnerabilities Catalog.
Risk and Threat Considerations
This kind of firmware flaw is risky because exploitation happens below the layers many organisations monitor well. If a trusted execution component can be driven into an unsafe memory write, the attacker may gain a path to crash the device, read sensitive data, or weaken trust assumptions that other controls depend on.
Failure mechanism: An attacker reaches the vulnerable secure-function path from the non-secure environment and triggers memory corruption in trusted firmware, creating the possibility of data exposure, system halt, or other integrity-impacting behaviour.
Impact: The practical consequence can extend beyond a single device failure, because compromised firmware trust can undermine platform reliability, complicate recovery, and expose sensitive material that was assumed to be protected by the secure boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Active exploitation status directly informs vulnerability prioritization and risk response. |
| Recommendation — Prioritise KEV-listed firmware exposure in your risk register and remediation workflow. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The question is about confirming exploited vulnerability exposure and response urgency. |
| Recommendation — Track the affected firmware in vulnerability scanning and exposure monitoring. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV status makes this a vulnerability triage and remediation priority question. |
| Recommendation — Escalate KEV-listed firmware issues through continuous vulnerability management. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Firmware exploitation can expose trusted components and adjacent secrets in platform environments. |
| Recommendation — Review firmware-adjacent deployment settings that can widen trust-boundary exposure. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | The flaw is an exploited memory corruption path that can alter privileged system behaviour. |
| Recommendation — Map observed exploitation to privilege-escalation and memory-corruption detection logic. | ||
Practitioner Guidance
What to prioritise: Treat any KEV-listed firmware CVE as an urgent exposure item, then sort affected assets by whether they host sensitive workloads, enforce secure boot, or underpin shared platforms. That ordering helps you focus first on the systems where compromise would create the largest security or operational impact.
What to verify: Confirm the exact firmware lineage, not just the device model. Firmware vulnerabilities are often inherited through board support packages, vendor forks, or image reuse, so the remediation decision should be based on the actual build in use.
Practitioner takeaway: For KEV-listed firmware issues, the key decision is not whether exploitation is possible in theory, but whether the vulnerable image is deployed anywhere that makes compromise materially expensive, persistent, or hard to detect.
Related resources from NHI Mgmt Group
- Guide: Mobile Device Security Guide
- How do you patch or mitigate CVE-2021-27562 (Arm Trusted Firmware Out-of-Bounds Write)?
- CVE-2021-27562 (Arm Trusted Firmware Out-of-Bounds Write)
- Is CVE-2021-22555 (Linux Kernel Heap Out-of-Bounds Write) being exploited in the wild?
- Is CVE-2021-30900 (Apple iOS, iPadOS, and macOS Out-of-Bounds Write) being exploited in the wild?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org