
This week brought two security issues that customers have asked us about: a compromise at the certificate authority eMudhra, and a critical PHP security release. This post covers what happened, our assessment of each, the steps we're taking, and what you may want to check in your own environment.
A certificate authority vouches for a website's identity. Its keys sign the certificates browsers and servers use to set up a secure connection. On October 17, 2026, the private keys of eight intermediate certificates operated by eMudhra under its emSign brand were reported compromised. Anyone holding one of those keys could issue certificates that look legitimate.
The industry responded quickly:
If you use an up-to-date browser, you're already protected. Mozilla's announcement has the full details.
Connections to Courier. No Courier certificate is issued by eMudhra or emSign. When you call Courier's API, sign in to the Courier app or visit our website, the connection doesn't depend on any affected certificate.
Connections from Courier. Courier also makes outbound connections, for example when we deliver webhooks to your endpoints or send messages through delivery providers. We are rolling out the Node.js security releases published October 21, 2026, to these services. These releases remove the affected eMudhra roots from Node.js's trusted certificates and reject any certificate chain that uses one of the compromised keys. The rollout is in progress, and we expect to complete it by October 22, 2026.
Customer data. We have found no impact to customer data or services.
Browsers handle this automatically. Servers often don't. If your own services make HTTPS connections, including services that receive Courier webhooks or use Courier's SDKs, make sure you're running current versions of:
On October 21, 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 under CVSS v4.0, and both could allow unauthenticated remote code execution on PHP servers that handle web requests. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Courier's platform is not affected. Courier's production services don't run PHP.
If you use Courier's PHP SDK: the SDK is open source and runs in your environment, on your own PHP installation and HTTP client. The vulnerabilities are in PHP itself, not the SDK, so the SDK doesn't need a change. Update PHP to one of the fixed versions above.
We'll keep monitoring both issues and will update this post once our rollout is complete. If you have questions or need documentation for a security review, contact us at security@courier.com.

Control how fast Courier sends to your providers
You shouldn't have to think about how fast you send to Courier. Set a send rate limit on any provider, and Courier sends your notifications to it at the rate you choose. Anything over the limit is queued, not dropped.

Know the moment users change notification preferences
Every preference change in Courier now reaches your systems two ways. A `preferences:user:updated` webhook fires the moment a user opts in, opts out, or changes a topic's channels, wherever they made the change. `GET /preferences/logs` returns the history, newest first, with the previous value where Courier knows it. Keep your CRM, warehouse, or marketing tools in step with what users chose.

Test Courier emails end to end with your AI agent
Give your coding agent an AgentMail inbox, and it can test your Courier emails the way a user would: send the change, check what arrives, review how it renders, and fix what it finds before the change reaches Production.