Loading story…
Arch Linux's mkinitcpio version 42-1 adds systemd-pcrphase.service to the systemd hook, matching the intended behavior introduced in systemd v261. The service changes TPM Platform Configuration Register measurements for PCRs 0-7, 9, and 12-14, affecting systems whose LUKS volumes are automatically unlocked through TPM2 policies bound to those measurements.
Administrators must re-enroll affected TPM2-bound LUKS unlock configurations before or after deploying the update to avoid boot-time unlock failures. Systems using pinned PCR values should follow systemd-cryptenroll guidance; deployments using custom PCR policies with systemd-pcrlock-make-policy.service disabled should instead use the systemd-pcrlock documentation to regenerate or update their policies.
See real exploitation activity before you spend the cycle.
1 event from the most recent confirmed update back to the earliest known activity.
Starting with mkinitcpio version 42-1, the systemd hook includes systemd-pcrphase.service, changing TPM PCR measurements for PCRs 0-7, 9, and 12-14. Systems using those PCR values for TPM2-bound LUKS unlocking must re-enroll their unlock configuration.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Microsoft said some **Windows Server 2025** devices may enter **BitLocker recovery** after installing the April 2026 `KB5082063` security update, affecting systems with a specific and discouraged BitLocker Group Policy tied to TPM platform validation, PCR7, and Secure Boot conditions during transition to the **2023-signed Windows Boot Manager**. The company said the recovery key prompt should typically appear only on the first restart, is preparing a fix, and advised administrators to remove the problematic policy before deployment or use **Known Issue Rollback**; the issue is mainly expected in enterprise-managed environments rather than personal devices. Separately, researchers disclosed **BitUnlocker**, a downgrade attack that can expose data on BitLocker-protected **Windows 11** systems in under five minutes with physical access by exploiting `CVE-2025-48804` in the Windows Recovery Environment. The attack works because Secure Boot may still trust older **Microsoft Windows PCA 2011**-signed boot managers, allowing a pre-patch `bootmgfw.efi` and modified WinRE chain to launch `cmd.exe` with the encrypted volume already mounted; systems using **TPM-only** BitLocker remain at risk unless organizations migrate trust to **Windows UEFI CA 2023** via `KB5025885` or require **TPM+PIN** pre-boot authentication.
Jun 29, 2026
A disclosed zero-day in **HP ThinPro 8 and 9** allows an attacker with physical access to bypass TPM-backed full-disk encryption and recover the **LUKS** key protecting the root partition on affected HP thin clients. The weakness stems from incomplete TPM boot measurements: the sealed key is reportedly tied to PCRs covering the BIOS, option ROMs, and parts of the boot chain, but not the Linux kernel or `initramfs`. That gap lets an attacker alter an unencrypted `initramfs` to capture the legitimate disk-encryption key without changing the PCR values checked before key release. The issue was confirmed on **HP t530** and **HP t540** devices running ThinPro 8.1.0 build 22 and ThinPro 9.0.0 build 15. After modifying the boot components, an attacker can reinstall the drive, allow the device to boot normally, and then retrieve the raw key from the unencrypted boot partition for offline decryption, exposing the encrypted root filesystem and data such as device configuration, certificate stores, stored credentials, and password hashes. Researcher Darren McDonald reported the flaw to HP PSIRT, and HP reportedly said a fix was in quality assurance, but no **CVE**, security bulletin, or patch was available at disclosure time.
Aug 12, 2026
Microsoft issued a Secure Boot playbook telling organizations to update Windows and firmware trust chains before older Secure Boot certificates begin expiring in June 2026. The guidance says Secure Boot relies on CA-backed keys in UEFI firmware to validate trusted boot components and reduce exposure to early-boot malware, and ties the certificate refresh to protections against the **BlackLotus** bootkit issue tracked as `CVE-2023-24932`. Microsoft said many PCs built since 2024 already include the newer 2023 certificates, while other systems may need monthly Windows updates, OEM BIOS/UEFI updates, or both. The company recommended a phased rollout that starts with device inventory and Secure Boot status checks, then pilots updates and validates success through registry keys and Windows Event Log indicators. Enterprise administrators reported that Windows updates alone may not be sufficient on all hardware, particularly for Lenovo and other systems that still require vendor firmware updates to ensure compatibility and load the new certificates into UEFI defaults. Practitioners also warned that automatic certificate deployment can depend on factors such as firmware readiness, telemetry, and whether devices fall into Microsoft's higher-confidence rollout groups. Operational concerns raised include multiple reboot cycles, possible **BitLocker** impacts, scheduled task triggers, and the need to update related Secure Boot-dependent assets including servers, virtual machines, PXE images, and recovery media.
Aug 5, 2026