DigiCert filed a Final Incident Report on the Mozilla CA compliance tracker (Bug 2033170) describing a compromise that began with a malicious file sent through the company's customer support chat channel, ended with the misissuance of 27 EV code-signing certificates later used by the threat actor to sign the Zhong Stealer malware family, and was ultimately disclosed to DigiCert by an external researcher rather than caught by DigiCert's own detection. 60 certificates were revoked in total (the 27 confirmed-misused, plus 33 more revoked precautionarily because the threat actor may have accessed their initialization codes). The misissuance is the operative incident; the delivery vector and the gaps that let it succeed are what operators outside DigiCert should pay attention to.
Framing note: this bulletin draws on a single primary source — DigiCert's own incident report on Bugzilla Bug 2033170 — and on no other reporting. Where the bulletin offers operator guidance beyond what that report covers, it is flagged as the bulletin's recommendation rather than DigiCert's. Several customer-impact details (which third-party organizations' customer accounts were affected, what malware family the misissued certificates were used to sign, threat- actor attribution) are not asserted here because they are not in the source the bulletin is built on.
Three things make this incident worth wider operator attention than the customer set directly affected. (1) The malware bears valid Authenticode signatures from a public CA. Endpoint allowlists and security stacks that treat "valid Authenticode signature," "trusted publisher," or "EV code-signing signature from a major CA" as a sufficient allow signal without additional behavioral or reputational checks may have reduced their detection margin against the malware these 27 certificates were used to sign. (2) The vector was the help desk. Customer support is the one role in any organization explicitly designed to accept files from strangers. The same delivery pattern works against any company whose support staff receive customer attachments through a chat channel. (3) Detection happened externally. DigiCert's investigation closed after containing the first infected machine; an external researcher's tip about certificates being used to sign malware in the wild led to the discovery of a second infected machine that had been the actual source of the certificate theft. The contained-and-cleared verdict was wrong, and the gap was invisible to DigiCert until an outsider provided the evidence.
What happened, per Bug 2033170
DigiCert's own incident report describes the timeline as follows. All of the following bullets are paraphrased from that report.
-
2026-04-02. A threat actor contacted
DigiCert's customer support team through a chat channel,
posing as a customer. The lure was a ZIP file presented as
a screenshot. Inside the ZIP was a
.screxecutable carrying a malicious payload. (On Windows,.scris a screensaver file format, but it is executed as a normal Portable Executable. The format has been a malware-delivery vector for decades.) -
Endpoint security blocked four delivery
attempts. The fifth attempt succeeded and
compromised
ENDPOINT1, a machine used by a support analyst. -
2026-04-03. DigiCert's Trust Operations
team detected the infection on
ENDPOINT1, contained it, investigated, and concluded the incident was contained. - 2026-04-05 through 2026-04-14. DigiCert received certificate problem reports from third parties about DigiCert-issued code-signing certificates being misused in the wild. These were initially handled as normal code-signing-abuse reports. As the pattern developed, the Support team intensified review, and on 2026-04-14 the scope changed and Trust Operations became re-engaged.
-
2026-04-14 to 2026-04-17. The re-engaged
investigation discovered a second compromised
machine,
ENDPOINT2, belonging to a different support analyst. It had been infected through the same vector during the same window. CrowdStrike was not installed onENDPOINT2, creating an EDR coverage blind spot; the original investigation had not checked EDR enrollment status for all exposed users, which is why the second machine went undetected the first time. - The mechanism of certificate theft. The compromised analyst sessions gave the threat actor access to DigiCert's internal customer support portal. That portal permits authenticated support staff to view limited customer-account information, including initialization codes for EV code-signing certificates that customers had ordered but not yet retrieved. Per DigiCert's report, possession of an initialization code combined with an already-approved order is sufficient to obtain and activate the resulting certificate. The threat actor used this combination to obtain real, validly-issued EV code- signing certificates from multiple DigiCert intermediate CAs, across a finite set of customer accounts.
- 27 certificates explicitly attributed to the threat actor. Of these, 11 were identified through certificate problem reports submitted to DigiCert by community members linking the certificates to malware observed in the wild; the remaining 16 were identified during DigiCert's internal investigation. As a precaution, DigiCert revoked an additional 33 certificates whose initialization codes the threat actor may have viewed. Total revocations: 60.
- Revocations occurred within 24 hours of identification, with revocation dates set back to each certificate's date of issuance. Pending orders within the window of interest were cancelled.
The four CAs from which DigiCert revoked certificates, per the report:
DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1 DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1 Verokey High Assurance Secure Code EV
A CSV of full certificate details is attached to the Bugzilla
report as Bugzilla_2033170_Appendix.csv. If you
need to determine whether a specific certificate your
organization received from DigiCert is in the revocation set,
the appendix is the authoritative source.
Three contributing factors DigiCert identified
The Bug 2033170 report names three contributing factors to the incident. They are paraphrased here:
-
File-type filtering on the support chat channel did
not block
.screxecutables. The delivery vector should have been categorically refused before reaching the analyst's machine, regardless of endpoint defenses downstream. -
EDR coverage was inconsistent. CrowdStrike
was not installed on
ENDPOINT2, creating an EDR coverage blind spot. The original investigation did not check EDR enrollment status for all exposed users, which is why the same intrusion went undetected on the second machine while being caught on the first. - Initialization codes for code-signing certificates were not adequately protected within the support portal. A support-staff role with a legitimate need to view customer accounts also had visibility into material that, when combined with an approved order, functions as the cryptographic equivalent of "press here to issue a real certificate."
Priorities, by relationship to the incident
The operative population for this bulletin splits into three groups: DigiCert customers whose orders may have been touched, anyone whose endpoint or allowlisting strategy treated "signed by a public CA" as a positive trust signal, and everyone else (for whom this is an architectural lesson rather than an incident-response item).
| Priority | Workload | Why |
|---|---|---|
| Highest | DigiCert EV code-signing customers with orders placed but not yet retrieved during the exposure window | Check whether any of your DigiCert-issued certificates appear in the appendix CSV attached to Bug 2033170. If so, the certificate has been revoked; you need a re-issuance and your software-distribution pipeline needs to switch to the new certificate. Cancelled-order status should also be checked for orders that were in flight during early April. |
| Higher | Environments using EDR or application-allowlisting policies keyed on Authenticode publisher trust | The misissued certificates were validly signed by trusted DigiCert intermediate CAs and bore the names of legitimate code-signing customers. Environments that treat a valid Authenticode signature, trusted publisher, or EV code-signing status as a sufficient allow signal — without additional behavioral or reputational checks — may have reduced their own detection margin against malware signed by these certificates during the window before revocation propagated. Audit your allowlist policies; consider hash-based or behavioral allowlisting where signature-based trust is brittle. |
| Medium | Any organization with a customer-support team that accepts file attachments through a chat channel | The delivery vector is generic: a stranger sends a file disguised as something benign, the support agent opens it because that is the role's job, and endpoint defense is the only thing standing between the attachment and the agent's session. Review the file-type filtering on your support intake channels (chat, ticket attachments, email). Block executable extensions categorically, including the long tail (.scr, .cpl, .lnk, .iso, .img, .vhd, .msi, etc.) before the file ever reaches an analyst. |
| Medium | Any organization where internal portals expose initialization codes, one-time secrets, or "approve-and-collect" tokens to staff with a legitimate viewing need | The DigiCert support portal had a legitimate function — letting support staff see the customer's view — that turned out to also expose material with cryptographic-issuance value. Audit your own internal tools for the same pattern: any token, code, or secret that a staff role can see for support reasons but is also sufficient to act on its own. Mask, redact, or break the link between viewing and acting wherever possible. |
| Lower | Everyone else | The incident is meta-news for organizations not in any of the above categories. The architectural takeaways — Authenticode signatures from public CAs are not by themselves a clean bill of health, support channels are an attractive vector, contained-and-cleared verdicts can be wrong if EDR enrollment is uneven, and device-bound auth does not protect a portal when the device itself is compromised — are worth recording in your threat model, but no immediate action is required. |
Categorization source: Bulletin's framing based on the contributing factors DigiCert listed in Bug 2033170, applied to the operator-side roles those factors generalize to.
Am I affected?
The DigiCert-customer question is the most concrete one to answer:
-
Pull the appendix CSV from Bug 2033170
(
Bugzilla_2033170_Appendix.csv, attached to the bug). Cross-reference against your inventory of DigiCert EV code-signing certificates by serial number, common name, or thumbprint. - Check your DigiCert account portal for cancelled orders in the early-April 2026 window. Orders that DigiCert cancelled precautionarily will need to be re-submitted.
- If a revoked certificate was used to sign software you distributed during the window between issuance and revocation, the signed binaries may fail signature- or reputation-checks depending on whether the signature was timestamped, the consuming platform's revocation-checking behavior (online OCSP / CRL versus cached, hard-fail versus soft-fail), updater policy, and endpoint enforcement. The operational impact ranges from "no user-visible effect" on platforms that respect a valid timestamp from before revocation, to "all signature-validity prompts now show revoked" on platforms that hard-fail on current revocation regardless of timestamp. Map your distribution targets, re-sign and re-publish with a fresh certificate where appropriate, and coordinate with downstream distributors and customers — OCSP / CRL checks may already be returning "revoked" for previously-shipped binaries on some endpoints.
- Verify that your software update infrastructure gracefully handles certificate-revocation conditions on the client side. Updaters that hard-fail on revoked- signature should not silently degrade; updaters that silently accept revoked signatures should not.
If you are not a DigiCert customer but operate Windows fleets with publisher-trust EDR allowlisting, consider whether any of the publishers whose names appeared on the misissued certificates have any pre-existing trust status in your environment. This bulletin does not assert which publishers were affected; consult the appendix CSV attached to Bug 2033170 for the authoritative list, or your EDR vendor's advisory if they have published one.
Architectural takeaways
Three observations from the Bug 2033170 report worth carrying forward, independent of the immediate response:
First, support channels are intake by design. The role is structured to accept attachments from strangers, and the staff serving that role will open files because that is what serving the customer requires. Treating support analysts as a population that can be trained out of opening attachments is an unrealistic model. The defense has to be structural: refuse executable file types at the channel boundary, run support-staff sessions in environments where a compromise is contained by design (separate identity, no lateral reach to internal portals or production systems, ephemeral browser/desktop), and audit the EDR agent health of those endpoints with higher frequency than the rest of the fleet because they are the standing target.
Second, "viewing" and "acting" need to be distinct privileges, even within the same UI. The DigiCert support portal exposed initialization codes to staff with a legitimate viewing need, in a system where seeing the code and having a corresponding approved order was sufficient to complete issuance. Any internal tool that combines a reasonable read-permission with a token whose mere visibility enables action falls into the same pattern. Audit for it: API keys displayed in customer-account views, one-time codes visible during onboarding flows, recovery secrets surfaced for support-side troubleshooting, "view as customer" impersonation features that surface anything that wouldn't be shown to a customer-service screen-share.
Third, contained-and-cleared verdicts on the first detected machine are insufficient when EDR coverage is uneven. DigiCert's first investigation was scoped to the infection it had detected. The second machine was compromised through the same vector at the same time and remained undetected because CrowdStrike was not installed on it, and the original investigation did not check EDR enrollment status across all exposed users. The lesson the report invites: when a vector has been confirmed, the scoping question is not "did this machine catch fire" but "which machines could have caught fire and did our detection actually run on all of them." Fleet-wide EDR-enrollment and agent-health audits are the natural follow-up to any contained-vector incident, not a separate hygiene activity.
Fourth, device-bound authentication does not help when the device itself is the thing the attacker is operating from. DigiCert's report notes that Okta FastPass — a device-bound, phishing-resistant authentication mechanism designed specifically to defeat credential-replay and adversary-in-the-middle attacks — was effectively bypassed in this incident because the attacker was operating from the compromised analyst session on the compromised endpoint, with the device's authentication material already present and already trusted. Device-bound auth raises the bar against remote credential theft; it does not raise the bar against an attacker whose initial foothold is the device itself. For any portal that grants meaningful blast-radius — support tools, certificate-issuance interfaces, admin consoles — the auth story has to assume that "this user is on a trusted device" can mean "an attacker is in the user's session on a trusted device that has been compromised." Step-up controls keyed on session anomalies, transaction-level approvals for issuance- class actions, and mandatory dual-control for portal operations that mint credentials are the natural next layer.
This bulletin does not assess threat-actor attribution, customer impact beyond the appendix, or secondary reporting about the Microsoft Defender false positive that affected DigiCert root certificates around the same window. The Bugzilla report does identify the malware family as Zhong Stealer, but does not itself establish broader attribution beyond that, and naming a threat-actor cluster is left to the independent researchers who have published on it. Separate public reporting and DigiCert's own blog discuss a Microsoft Defender signature-update false positive affecting DigiCert root certificates; this bulletin does not analyze that separate Defender issue, which DigiCert characterizes as not a compromise of DigiCert certificates and which Microsoft addressed via subsequent signature updates.
If your organization is a DigiCert EV code-signing customer: cross-reference your certificate inventory against the appendix attached to Bug 2033170, re-issue any revoked certificates, and re-sign affected software. If your organization runs a customer support channel that accepts file attachments: verify that executable file types are refused at the channel boundary and audit EDR-agent health on support-staff endpoints. If your organization runs internal tools that expose tokens, codes, or secrets to staff with a "view-as-customer" type permission: audit for cases where viewing is sufficient to act. The DigiCert incident is the concrete example; the pattern is general.