---
title: "emBarrass: Putting the “em” in MITM."
tldr: "We shipped detection rules in Boost Security Developer Endpoint Protection and Dazio. Now meet emBarrass: our open-source tool for showing whether your everyday developer tools still trust a weak CA key."
author: Boost Security Labs
date: 2026-10-21
category: tools
featured: false
tags:
  - embarrass
  - certificate-authorities
  - tls
  - developer-endpoint
  - open-source
banner: /images/articles/introducing-embarrass-banner.svg
bannerMobile: /images/articles/introducing-embarrass-banner-mobile.svg
bannerAlt: "emBarrass: Putting the “em” in MITM. Colorful terminal-inspired example results: curl embarrassed, gh trust held, npm no signal."
---

**TL;DR**: Earlier today, we shipped detection rules for the weak CA keys in both [Boost Security Developer Endpoint Protection](https://boostsecurity.io/solution/developer-endpoint) and [Dazio](https://boostsecurity.io/dazio). Now meet [emBarrass](https://github.com/boostsecurityio/emBarrass): wrap a command, present a forged certificate, and find out whether your everyday developer tools take the bait.

---

The emSign / eMudhra key ceremony failure put eight intermediate CAs into service with private keys so weak they could be recovered in milliseconds. One private key was **4**. Apparently, protecting internet trust was a bring-your-own-entropy event. [Scott Helme's write-up](https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/) has the full, painful recap.

The catch for developers: browser mitigations don't automatically protect your Git client, package managers, or CLI tools. They can make different TLS trust decisions on the very same machine.

<div class="takeaway-callout">
<div class="takeaway-callout-header"><span class="lu-pulse" aria-hidden="true"></span><span class="lu-title">HERE'S THE MAIN TAKEAWAY</span><span class="lu-sub">Nobody hacked eMudhra. Anyone can recover these keys from the public certificates.</span></div>

You grab a latte and join the café's free Wi-Fi. Or the airport's, the hotel's, the conference's. You get a little work done. Anyone on that network can mint a valid-looking certificate for `github.com`, your package registry, or your cloud provider's API. If your CLI still trusts it:

- `git push` and `gh` hand over your GitHub token, and with it every private repository you can read.
- Cloud CLIs like `gcloud` and `aws` carry the tokens and session keys that reach production.
- `npm install` or `curl | sh` runs whatever the attacker decides to serve.

No warning, no padlock to check. Just a coffee that cost you prod.

</div>

[At Boost Security](https://boostsecurity.io/), this triggered emergency patching across our own products, tools, and services. We also built detection rules for this issue into both [Boost Security Developer Endpoint Protection](https://boostsecurity.io/solution/developer-endpoint) and [Dazio](https://boostsecurity.io/dazio). **Those rules shipped earlier today.**

But we also wanted something you could *feel*.

With [SmokedMeat](/articles/introducing-smokedmeat/), we put pipeline attacks in defenders' hands because seeing an exploit land makes the urgency click. This incident deserved the same treatment.

Meet **[emBarrass](https://github.com/boostsecurityio/emBarrass)**, our open-source tool for finding out whether the commands you use every day still accept a certificate signed with a weak CA key.

**Quickstart:** With Go 1.27.3 or later installed, clone the [repo](https://github.com/boostsecurityio/emBarrass), install, and wrap a command:

```sh
git clone https://github.com/boostsecurityio/emBarrass.git
cd emBarrass
make install
embarass curl --silent https://example.com/
```

Make sure your Go binary directory (`GOBIN`, or `GOPATH/bin` when unset) is on your `PATH`.

emBarrass presents a forged certificate through a local proxy. If your command accepts it and starts sending application data, you get your answer: that executable, on that machine, still trusts the tested chain.

<img src="/images/articles/inline/introducing-embarrass-single-command.png" alt="Example from the emBarrass README: curl accepts a forged TLS certificate, and emBarrass terminates the child process after detecting application data." width="700" loading="lazy" />

Certificate verification stays enabled. Your trust store stays intact. The intercepted request never goes upstream.

For a broader reality check, batch mode discovers installed tools and previews the probes before running them:

```sh
embarass batch
```

![Example batch results from the emBarrass README, showing embarrassed, trust held, and no signal outcomes across developer tools.](/images/articles/inline/introducing-embarrass-batch.png)

A vulnerable result shows the TLS trust failure an attacker on your network path could exploit for a man-in-the-middle attack. An inconclusive result means the test couldn't establish an answer; a rejection applies to the executable and chain you tested.

The [usage guide](https://github.com/boostsecurityio/emBarrass#usage) explains how to test both affected trust paths.

**Give your toolchain an awkward moment before somebody else does.**

[Grab emBarrass on GitHub](https://github.com/boostsecurityio/emBarrass), test your everyday tools, patch, and test again.