CVE-2016-9963

What it actually does

The flaw in Exim exposes the private DKIM signing key in log files and bounce messages, allowing unauthorized retrieval of sensitive cryptographic material used for email authentication.

Why it matters to the business

Attackers obtaining the key can forge authenticated emails from the affected domain, leading to reputational damage, increased phishing success, and potential loss of trust in email communications; the issue affects widely deployed email servers on Linux distributions with no ransomware usage reported.

How an attack unfolds

An attacker sends crafted messages that trigger bounce generation or logging paths in vulnerable Exim versions, then accesses the resulting log entries or bounce content containing the embedded private DKIM key; no named threat actors or campaigns are associated with this disclosure vector.

How to fix it

Upgrade Exim to version 4.87.1 or later on all affected systems including Ubuntu and Debian Linux distributions; disable verbose logging of DKIM operations where possible until patched; monitor vendor advisories for exact package versions in each distribution.

How to confirm the fix worked

Verify installed Exim version is 4.87.1 or higher; inspect mail logs and bounce templates for absence of private key material; test DKIM signing functionality post-upgrade to confirm no leakage occurs.

Typical attack path

1. Identify an Exim instance prior to 4.87.1 processing DKIM-signed mail
2. Trigger delivery failures or logging events that include key material
3. Retrieve the private key from accessible bounce messages or log files
4. Use the key to sign and send forged emails appearing to originate from the domain

How to detect it

Search mail server logs and bounce message archives for strings containing DKIM private key blocks or related headers; examine historical log files for any instances where key material appears alongside bounce or delivery failure entries.

• DKIM private key blocks appearing in mail logs or bounce files
• Exim process logs containing base64-encoded RSA private key data near delivery failure entries

What your security team should do

• Prioritize upgrade of all Exim installations to 4.87.1 or newer within standard change windows given the 2017 disclosure date and stable low EPSS
• Audit DKIM key handling procedures and rotate any keys potentially exposed in historical logs
• Review log retention and access controls to prevent future key leakage
• Include Exim version checks in regular vulnerability scanning