--- type: Article title: "Styled to Steal: The Overlooked Attack Surface in Email Clients" description: "Injecting standard CSS into an encrypted email lets an attacker read its decrypted text: attacker-crafted font ligatures give the plaintext a content-dependent width, container queries measure that width, and each width loads a distinct remote image. Plaintext comes out character by character with no JavaScript, in Thunderbird and KMail." resource: "https://doi.org/10.1145/3719027.3765189" tags: [article, webseclist-reference, css-injection, info-leak, sanitizer-bypass, side-channel, css, email, owasp-a03-2021, owasp-a05-2021] generated: by: webseclist-refs/1 at: "2026-08-14T01:10:30+00:00" status: stable stale_after: 2027-08-14 sources: - id: original resource: "https://doi.org/10.1145/3719027.3765189" title: "Styled to Steal: The Overlooked Attack Surface in Email Clients" author: Leon Trampert, Daniel Weber, Christian Rossow, Michael Schwarz also_at: [] authors: - Leon Trampert - Daniel Weber - Christian Rossow - Michael Schwarz canonical_url: "" cited_by: - "2025.md:98" commit: "" content_sha256: 6a2bf5d53e5e9b9f7045a47722bc5ecede280de1d2d163694206ea175fa89d79 depth: full depth_reason: default kind: article language: "" licence: unknown original_url: "https://doi.org/10.1145/3719027.3765189" published: "" publisher: "" publisher_english: "" raw_sha256: 0a5edb59a6bc8eb947f3dabb03dbebdf31e594aed99ca6844ab355bf48e4c9d3 retrieved_from: "https://doi.org/10.1145/3719027.3765189" retrieved_kind: manual-import retrieved_utc: "2026-08-14T01:10:30+00:00" slug: styled-steal-overlooked-attack-surface-email-clients snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # Styled to Steal: The Overlooked Attack Surface in Email Clients **Styled to Steal: The Overlooked Attack Surface in Email Clients** - Leon Trampert, Daniel Weber, Christian Rossow, Michael Schwarz, Publisher not stated. - Published: date not stated - Original: - Preserved from: https://doi.org/10.1145/3719027.3765189 (manual-import) on 2026-08-14 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. # Styled to Steal: The Overlooked Attack Surface in Email Clients Styled to Steal: The Overlooked Attack Surface in Email Clients Leon Trampert Daniel Weber leon.trampert@cispa.de daniel.weber@cispa.de CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Saarbrücken, Germany Saarbrücken, Germany Christian Rossow Michael Schwarz rossow@cispa.de michael.schwarz@cispa.de CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Saarbrücken, Germany Saarbrücken, Germany Abstract CCS Concepts Email is still a widely used communication medium, particularly • Security and privacy → Web application security; Software in professional contexts. Standards such as OpenPGP and S/MIME security engineering. offer encryption while maintaining compatibility with existing in- frastructure. Within the end-to-end encryption threat model, email Keywords servers are untrusted, which creates opportunities for attackers to Email Client; PGP; CSS; Content Exfiltration inject malicious HTML or CSS into encrypted emails—either live during email transport, or by re-sending leaked emails. ACM Reference Format: In this paper, we show that isolation mechanisms in widely Leon Trampert, Daniel Weber, Christian Rossow, and Michael Schwarz. 2025. Styled to Steal: The Overlooked Attack Surface in Email Clients. In used email client software remain inadequate. We present a novel Proceedings of the 2025 ACM SIGSAC Conference on Computer and Commu- scriptless attack that extracts arbitrary plaintext from encrypted nications Security (CCS ’25), October 13–17, 2025, Taipei, Taiwan. ACM, New emails using only CSS without requiring JavaScript. Once the email York, NY, USA, 15 pages. https://doi.org/10.1145/3719027.3765189 is opened, three benign-looking CSS features—container queries, lazy-loaded web fonts, and contextual font ligatures—map each character of the ciphertext-carried plaintext to a unique network 1 Introduction request to the attacker’s server. This attack technique can incre- Despite the widespread availability of secure end-to-end encrypted mentally reconstruct the entire plaintext in a single rendering pass, messaging applications, email remains a popular and widely used with no JavaScript, no visual artifacts, and depending on the config- communication medium, especially in professional settings. While uration, even without any user interaction. The technique differs emails are typically transferred over TLS-encrypted connections considerably from prior work: it achieves complete plaintext re- from hop to hop, every email server involved in email delivery covery without script execution, evades state-of-the-art sanitizers sees email contents in plain [13]. As a result, two popular end-to- such as DOMPurify, and succeeds across multiple browser engines. end encryption standards, OpenPGP [3] and S/MIME [49], have We demonstrate the severity of this threat on Mozilla Thunderbird emerged to protect email content. These technologies are fully and KMail, with end-to-end attacks successfully exfiltrating PGP- backward compatible with existing email infrastructure, allowing encrypted text from an email rendered in the latest version of the users to send encrypted emails via any email server. In particular, respective clients. Furthermore, we show that our technique affects inline PGP remains popular, as it allows users to send encrypted code integrity tools and sanitization techniques reused in software emails even when the recipient’s email client does not support PGP stacks, including Meta’s Code Verify. Our findings led to practical natively [42]. This is achieved by embedding the PGP-encrypted mitigations in Thunderbird, as well as a revision of Meta’s threat content directly in the email body. model to include CSS. These results underline the need for robust Within the threat model of end-to-end encryption, only the content isolation in email client software and challenge the as- sender and recipient, with their respective email clients, are trusted sumption that existing mitigations fully prevent encrypted content parties. Importantly, no involved email server has to be trusted. The leakage. email can be intercepted and modified by malicious parties, such as email providers, ISPs, or even state actors. This allows for mali- cious parties to inject untrusted content into the email body, which the email client of the recipient then renders. Moreover, leaked Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed encrypted emails can be resent to the original recipient, containing for profit or commercial advantage and that copies bear this notice and the full citation the encrypted content with additional injected untrusted content. on the first page. Copyrights for components of this work owned by others than the Such untrusted content can include HTML and CSS, which are author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission commonly used to format emails. We refer to an email containing and/or a fee. Request permissions from permissions@acm.org. encrypted content and untrusted parts as a mixed-context email. CCS ’25, Taipei, Taiwan In 2018, the Efail attack [39] demonstrated a direct content- © 2025 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 979-8-4007-1525-9/2025/10 exfiltration attack, where specifically crafted HTML injected by an https://doi.org/10.1145/3719027.3765189 attacker tricks the parser into including the decrypted PGP content CCS ’25, October 13–17, 2025, Taipei, Taiwan Leon Trampert, Daniel Weber, Christian Rossow, Michael Schwarz as part of a URL fetched from an attacker-controlled server, leaking Our attack introduces three critical innovations compared to pre- the content to the attacker. In response to this attack that affected at vious variants. First, we introduce a novel mechanism leveraging least five widely used email clients, including Mozilla Thunderbird CSS animations and lazy-loading fonts, enabling the incremental and Apple Mail, the security community has focused on preventing extraction of arbitrary plaintext content without multiple injections direct content exfiltration attacks. However, we argue that Efail is or user interactions, which is not possible with previous CSS-based merely an instance of a more general class of attacks that exploit attacks [18, 19, 26, 29, 37]. Second, unlike previous attacks requiring the lack of isolation between untrusted and trusted content. browser-specific features [18, 26, 29, 37], our approach relies exclu- In this paper, we revisit the attack surface from a “CSS-only” sively on regular CSS container queries–a recently standardized CSS angle and answer the following research questions: Have the miti- feature universally supported by all modern browser engines and gations against direct content exfiltration attacks fully closed multiple email clients. Third, we propose an adaptive, server-side the attack surface for content exfiltration attacks in email font generation method that dynamically builds ligatures based on clients? Can we still mount attacks using only HTML and previously leaked characters, enabling the practical and efficient ex- CSS that undermine email encryption in a single rendering traction of arbitrary-length text despite inherent font limitations. The pass, i.e., when simply opening an email? approach differs significantly from prior scriptless techniques: it We systematically analyze the current behavior of email clients needs no script execution, achieves full plaintext recovery instead of when rendering mixed-context emails. We find that while a direct only HTML-attribute recovery, works across multiple email clients, content-exfiltration attack, as in Efail, is no longer possible, at least and can even evade popular sanitizers such as DOMPurify because three widely used PGP-enabled email clients (Mozilla Thunder- the injected CSS is fully standard-compliant. bird, KMail, and Apple Mail with the GPGSuite plugin) still allow To demonstrate the security implications and severity of our untrusted stylesheets to be applied to PGP-encrypted content, show- attack, we conduct end-to-end attacks to fully recover the content ing a lack of isolation. Control over stylesheets is often ignored of end-to-end encrypted emails. The victim only needs to open or regarded as low-severity issues [40, 41], with existing scriptless a single email, from which we can reliably extract the decrypted (CSS-based) attacks being tailored to the web (i.e., browser) setting. content at a rate of 2 B/s for arbitrary text and instantly for text Existing attacks primarily focus on leaking HTML attributes, such in a known format (e.g., credit card numbers). The attack is fully as anti-CSRF tokens or the values of input fields [17, 21], but not stealthy, running in the background without any visual clue for the text. While there are some attacks that are capable of leaking text victim. Even worse, the attack is applicable to an email client that to some extent, they do not apply to the email context. Existing was previously unaffected by Efail’s direct exfiltration attack. This approaches typically rely on repeated interactions, scrollbars, or highlights that the mitigations against direct content-exfiltration browser-specific features, making them unsuitable for universally attacks are insufficient to prevent all types of content exfiltration. applicable real-world scenarios, such as email client exploitation. While not our primary focus, our technique also affects state- Thus, to answer the second research question, we introduce a of-the-art defenses against malicious content exfiltration in web novel scriptless attack using only CSS. Our proposed attack allows applications. First, the recent academic proposals [14] and indus- an attacker to exfiltrate arbitrary text from an encrypted email try implementations [27] regarding the concept of Accountable via the following four steps. (1) The attacker crafts a message con- JavaScript aim to vet JavaScript code. While initially targeting only taining the encrypted text for the recipient, combined with HTML JavaScript, Meta acknowledged the security impact of our attacks and CSS. (2) Upon opening, the client renders the payload, i.e., de- and extended their Code Verify browser extension [27, 28] to verify crypts the ciphertext and applies the attacker-provided stylesheet. the integrity of JavaScript and CSS. Thus, our attack shows an over- (3) Three standard CSS features—container queries, lazy-loaded web sight in the threat model of these defenses in that they focus only fonts, and contextual ligatures—encode each plaintext character to on JavaScript and not CSS, undermining the security guarantees. a unique request for a remote image to the attacker server. (4) The Second, HTML sanitizers aim to filter untrusted user input before loading of remote images incrementally leaks the entire plaintext inserting it into the DOM [20]. For example, the popular DOMPu- during a single rendering pass. The technique neither shows visual rify [20] sanitization library can be used to prevent DOM-based XSS. artifacts nor triggers warnings, yet recovers arbitrary text. Such HTML sanitization libraries do not protect against scriptless At the core, we apply fonts with specifically crafted ligatures to attacks in their default configuration, allowing attackers to leak the targeted text inspired by attacks against browsers [26, 29, 37]. web content. As such, the attack is highly relevant to sites that may If the defined ligature matches the content of the targeted text, it not be susceptible to XSS but still allow style injection. This can be applies a unique width to the text, which we can measure purely in due to sanitization or a strict script-restricting CSP. CSS. This still poses the major challenge of how to leak arbitrary Finally, to defend against our attacks, we discuss concrete miti- content in a single shot. To tackle this challenge, we leverage CSS gation strategies. For emails, we suggest restricting remote content animations to repeatedly apply fonts with different ligatures with- and strict content isolation between trusted and untrusted content. out having to reload the content or open the email multiple times. We advocate for stricter default configurations in sanitization li- Consequently, we can recover arbitrary text character-by-character braries. However, we fear that this only happens when there is and exfiltrate it via character-dependent remote-resource loading. sufficient awareness of the severity of these novel types of attacks. By relying on lazy font loading, we can dynamically craft fonts To summarize, we make the following contributions: with the required ligatures based on the already extracted text parts. (1) We systematically analyze the current behavior of email Thus, we do not require large fonts, allowing us to stay within the clients when rendering mixed-context emails. practical limits of fonts. Styled to Steal: The Overlooked Attack Surface in Email Clients CCS ’25, October 13–17, 2025, Taipei, Taiwan (2) We present a CSS-based scriptless attack that fully recovers content, such as text and attachments, it uses the multipart MIME arbitrary plaintext from encrypted emails, not just HTML format. This format divides the email into parts, each with its own attributes or short tokens. MIME-type header. A common multipart type is multipart/mixed, (3) We present end-to-end exploits to recover the content of which allows for specifying independent parts of different types. A PGP-encrypted emails in Mozilla Thunderbird and KMail. boundary string separates each part of a multipart email. (4) We present a proof-of-concept exploit against Meta’s Code PGP in Email. There are two main techniques to include PGP- Verify implementation of Accountable JavaScript. Meta con- encrypted content in emails. First, with PGP/Inline [42], the email sequently updated their implementation to also verify CSS. body directly contains the PGP-encrypted data. The body is usually (5) We showcase that the HTML Sanitizer DOMPurify does not of type text/plain and occasionally text/html. The approach is mitigate our scriptless attacks in its default configuration. usually only used to encrypt text and is regularly used with clients Outline. Section 2 provides background. In Section 3, we in- that do not natively support PGP, as it allows for easy interoperabil- troduce the threat model. Section 4 systematically analyzes email ity with plugins. An example of a third-party extension that lever- clients’ rendering behavior for mixed-context emails. Section 5 ages PGP/Inline is the Mailvelope browser extension, which enables presents an overview of our novel attack. Section 6 discusses its PGP encryption, e.g., on gmail.com. Second, with PGP/MIME [42], implementation. In Section 7, we present our real-world exploit the email body has the MIME type multipart/encrypted. It con- on Mozilla Thunderbird. In Section 8, we discuss mitigation ap- tains an entire email body, including, e.g., attachments, and allows proaches. Section 9 demonstrates the applicability of our scriptless for encrypting arbitrary MIME types. While PGP/MIME is preferred attack on the web. Finally, we discuss our results in Section 10. over PGP/Inline, it is not universally supported. Responsible Disclosure. We disclosed our findings regarding Thunderbird, KMail, and Apple Mail with the GPGSuite plugin to 2.2 Fonts Mozilla, KDE, and GPGTools & Apple, respectively. Mozilla will issue a fix for Thunderbird in the next stable release. The vendor Fonts are crucial for HTML rendering in both email clients and response from GPGTools indicates that the client is not exploitable. browsers. Modern font formats, such as TrueType [2] and Open- Meanwhile, KDE has acknowledged the issue and plans to fix it in Type [30], utilize outline-based representations to map characters an upcoming release. Furthermore, we have discussed the gap in the to visual forms. These formats define each character using mathe- default configuration of DOMPurify and Firefox’s HTML Sanitizer matical descriptions of lines and curves, ensuring scalability across API with the respective maintainers. While they acknowledge the different sizes and resolutions. Generally, fonts are shipped as files issue, they do not plan on changing the default configuration. Lastly, that contain tables that map characters to their visual represen- Meta has extended the threat model of the Code Verify extension tation, also known as glyphs. Content providers frequently ship to account for CSS as a response to our findings. custom fonts to ensure a consistent visual appearance of their con- Availability. Our artifact is available on GitHub at https:// tent. Notably, web developers may use the @font-face CSS rule to github.com/cispa/stylemail. Furthermore, it is archived at Zenodo load custom fonts from a remote server [6]. with the DOI: https://doi.org/10.5281/zenodo.17019769. TrueType and OpenType. TrueType is a font format initially de- veloped by Apple and Microsoft in the late 1980s. It is widely used 2 Background for both screen and print applications. OpenType is a successor of In this section, we provide the necessary background. We provide TrueType and PostScript Type 1 font formats [31]. It was introduced a brief overview of end-to-end encryption in the context of emails. in 1996 by Microsoft and Adobe Systems and supports advanced Additionally, introduce the modern font formats TrueType and typographic features, such as ligatures. TrueType has been partially OpenType and their relevant features. extended to support OpenType features, such as ligatures. Both formats are widely used on the web and universally supported. 2.1 End-to-end Encrypted Email Font Ligatures. Ligatures map two or more characters to a sin- While emails are typically transferred over TLS-encrypted connec- gle glyph [1]. In OpenType, there are different types of ligatures, tions from hop to hop, every email server involved in email delivery such as standard, discretionary, and contextual ligatures. The for- sees email contents in plaintext [13]. In 1991, Phil Zimmerman in- mer only leverages the preceding characters, while the latter two vented PGP (Pretty Good Privacy) encryption, later standardized can be context-dependent with their built-in conditional logic [1]. as OpenPGP by the IETF [3]. It provides cryptographic privacy and Ligatures are often used to improve the visual appearance of text, authentication to ensure that email servers (e.g., of the sender’s such as combining characters that would otherwise overlap or be or recipient’s email provider) cannot break the confidentiality or far apart. For example, the characters f and i are represented by a integrity of emails. Each communication party has a private and single glyph, fi, which moves their individual representations closer public key. The public key is used for encryption and signature together. Ligatures are crucial for many languages, such as Arabic, validation, and the private key is used for decrypting and signing. where the shape of a character depends on its position [57]. Structure. Generally, emails are structured with a header and body. The body contains the message content, which can be plain 3 Threat Model text, HTML, or a combination of other types. The type of content In our threat model, an attacker aims to recover the content of an is specified in the header using MIME (Multipurpose Internet Mail encrypted email. We assume the attacker can access such encrypted Extensions) types [45]. When an email contains multiple types of emails (e.g., from leaked emails or as a malicious party involved in CCS ’25, October 13–17, 2025, Taipei, Taiwan Leon Trampert, Daniel Weber, Christian Rossow, Michael Schwarz Email Client From: Alice From: Alice From: Alice To: Bob To: Bob To: Bob GET /leak1?c=S Attacker Attacker intercepts email sends email GET /leak2?c=E –BEGIN PGP MESSAGE– –BEGIN PGP MESSAGE– ENCRYPTED ENCRYPTED SECRET MESSAGE GET /leak3?c=C –END PGP MESSAGE– –END PGP MESSAGE– (a) Alice encrypts a secret message (b) The attacker adds a malicious (c) Bob opens the email, decrypts (d) Network requests leak the de- with Bob’s public key. stylesheet to the email. and renders the message. crypted content (see Figure 2). Figure 1: The end-to-end workflow of our attack. The attacker obtains a PGP-encrypted email. They then add a malicious stylesheet to the email. Upon opening the email, the victim’s client decrypts and renders the email. The malicious stylesheet and decrypted content are rendered in the same context, which allows for exfiltrating the content via network requests. sending or receiving emails). Note that in the first case, the attacker untrusted content. We systematically analyze PGP-compliant email does not have control over an email server. Moreover, the attacker clients. For each desktop platform, we select the most popular PGP- knows the intended recipient of the email, i.e., the victim. Without compliant email client and test the latest version available at the altering the encrypted block, the attacker wraps the original email time of writing (cf. Appendix D for a table of tested clients). Each inside a new HTML email, augments the message with arbitrary client is tested on a fresh installation with default settings. standard-compliant CSS, and sends this composite to the victim. We assume the victim opens the attacker’s email at least once, for the email client to decrypt and render the email content. Modern 4.1 Payload Construction and Evaluation email clients can decrypt and render such content automatically To test the susceptibility of an email client, we devise a broad range when the user opens the message, creating a mixed context in which of test cases. Most importantly, the email client has to support trusted plaintext is processed together with untrusted markup. PGP encryption, HTML emails, and remote content. We focus on Fundamentally, the attacker can only inject CSS and HTML, and HTML emails, as they provide the greatest attack surface and have no JavaScript. The attacker has no code execution on the victim’s been shown to be susceptible to a lack of isolation [39]. Further- system, and does not rely on classic software vulnerabilities [51]. more, not every email client allows the same methods for including Moreover, the attacker does not exploit any bug in the client but stylesheets. For each requirement of the vulnerability, we construct only relies on the lack of isolation between trusted and untrusted several emails that make use of the respective feature. Feature content. Our threat model largely follows the one of prior work [39]. support is determined based on the visual rendering of the email. As an example, to test the support for web fonts, we construct Scenario. Figure 1 illustrates the concrete steps for an attack. emails that include web fonts and some text that is styled using Alice writes Bob a PGP-encrypted email. An attacker who can ob- the web font. We test different inclusion methods, such as inline tain Alice’s email, e.g., on any involved email server, cannot read stylesheets, remote stylesheets, and data URLs. In total, we end up the plaintext but modify the email before delivering it to Bob, and with 5 test cases for this feature. Each test case is then sent to each thus inject a malicious stylesheet into the email. Bob receives and email client, where the email is opened manually and the visual opens the email, which is then rendered by his email client (e.g., rendering is inspected. For testing the support of remote content, Mozilla Thunderbird). The email client decrypts the PGP-encrypted we use remote images that are loaded via the tag and the message and renders it in the same context, i.e., document, as the background-image CSS property. malicious stylesheet. Depending on the email client and Bob’s set- First, we test for the support of inline stylesheets defined via tings, this step may require Bob to press a button to decrypt the