DigiCert Revokes Fraudulently Obtained Certificates Following Cyberattack On April 2, digital certificate authority DigiCert fell victim to a cyberattack after a threat actor targeted its support team with malware disguised as a screenshot in a customer chat channel. The malicious payload infected two endpoints one detected on April 3 and another on April 14, with the delayed discovery of the second infection attributed to malfunctioning security tools. The attackers exploited a limited-access function in DigiCert’s internal support portal, leveraging the ability of authenticated support analysts to proxy into customer accounts. This allowed them to obtain initialization codes for pending Extended Validation (EV) Code Signing certificate orders. With these codes and approved orders, the threat actor successfully issued fraudulent certificates across multiple customer accounts and certificate authorities (CAs). By April 17, DigiCert identified and revoked 60 certificates tied to the incident, including 27 directly linked to the attacker. Of these, 11 were reported by the cybersecurity community and had been used to sign the Zhong Stealer malware. The company confirmed that no other internal systems were compromised beyond the unauthorized access to initialization codes. In response, DigiCert revoked all potentially affected certificates, canceled pending orders to block further exploitation, and implemented stricter security measures. These include enforcing multi-factor authentication (MFA) for administrative workflows, restricting support users from accessing initialization codes, limiting file types in support chats and Salesforce case attachments, and enhancing logging capabilities.

Critical vulnerabilities were discovered in Lenovo’s AI-powered customer support chatbot, Lena, which leverages OpenAI’s GPT-4. The flaw stemmed from improper input and output sanitization, exposing the system to cross-site scripting (XSS) attacks. Security researchers at Cybernews demonstrated that attackers could exploit this by injecting malicious code via a 400-character prompt, tricking the AI into generating harmful HTML content. This enabled threat actors to steal session cookies, potentially granting unauthorized access to Lenovo’s customer support systems.The vulnerability highlighted significant risks in poorly secured AI implementations, particularly as enterprises accelerate AI adoption. While no evidence of active exploitation was reported, the flaw posed a serious threat to customer data integrity and system security. Had attackers successfully leveraged this, they could have compromised user sessions, accessed sensitive support-related information, or escalated privileges within Lenovo’s infrastructure. The incident underscores the urgency for robust AI security frameworks to prevent such exposures in high-stakes enterprise environments.

Lenovo devices running on vulnerable Insyde firmware were targeted by the BootKitty Linux UEFI bootkit exploiting the LogoFAIL flaws (CVE-2023-40238). BootKitty bypassed UEFI Secure Boot by injecting rogue certificates and exploiting vulnerabilities in UEFI image-parsing components through tampered BMP files. The bootkit was capable of disabling kernel signature verification, preloading malicious binaries, and targeting specific Ubuntu versions. Despite available security patches, many devices remained at risk. The incident served as a reminder of the dangers associated with unaddressed vulnerabilities and the importance of timely updates to safeguard devices in the field.

A significant security vulnerability has been discovered in Lenovo’s preloaded Windows operating systems, where a writable file in the Windows directory enables attackers to bypass Microsoft’s AppLocker security framework. The issue affects all variants of Lenovo machines running default Windows installations and poses serious implications for enterprise security environments. Key takeaways include the writable MFGSTAT.zip file bypassing AppLocker security due to incorrect permissions, the use of Alternate Data Streams to hide executables, and the persistence of the vulnerability from 2019 to 2025. Mitigation strategies involve removing the vulnerable file using PowerShell or other enterprise management tools.