DEV Community: Ercross

Vulnerability Report: GO-2026-6809 [Breakdown]

Ercross — Thu, 22 Oct 2026 08:33:48 +0000

𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟭𝟭𝟭𝟵𝟰𝟯 𝗺𝗲𝗮𝗻𝘀 𝗳𝗼𝗿 𝘆𝗼𝘂𝗿 𝗚𝗼 𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀

Go 1.27.3 and 1.26.10 shipped this week with a fix in 𝚌𝚛𝚢𝚙𝚝𝚘/𝚡𝟻𝟶𝟿. The changelog makes it sound small. It isn't, so here's the plain-English version.

𝗧𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺, 𝘀𝗶𝗺𝗽𝗹𝘆

When your Go code calls 𝚑𝚝𝚝𝚙.𝙶𝚎𝚝("𝚑𝚝𝚝𝚙𝚜://𝚊𝚙𝚒.𝚜𝚝𝚛𝚒𝚙𝚎.𝚌𝚘𝚖"), how does it know it's really talking to Stripe?

The server shows a certificate, like an ID card. Your program checks that the ID was stamped by an authority it trusts (a Certificate Authority, or CA).

Now imagine one of those authorities made its official stamps so badly that anyone could recreate them in seconds.

That's roughly what happened with eMudhra, an Indian CA. A flaw in their key generation produced 8 intermediate CA keys with almost no randomness. One key was literally the number 4. The others were small whole numbers under 256. Researchers recovered all of them from the public certificates in under a second on a laptop.

With one of those keys, an attacker can create a "valid" certificate for ANY domain: your bank, your payment provider, your own API. Your Go program would happily accept it. 😬

𝗪𝗵𝗲𝗻 𝗮𝗿𝗲 𝘆𝗼𝘂 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗲𝘅𝗽𝗼𝘀𝗲𝗱?

All of these have to be true:

Your Go program makes outgoing TLS connections (HTTP clients, gRPC clients, webhooks, database drivers with TLS)
It was built with Go older than 1.26.10, or 1.27.0 to 1.27.2
The machine or container it runs on still trusts the eMudhra roots (an old base image, a distro that hasn't shipped updated ca-certificates yet, or certs baked into a 𝚜𝚌𝚛𝚊𝚝𝚌𝚑/distroless image)
An attacker can get between your service and the server it's calling (a compromised network, DNS spoofing, a malicious proxy, shared Wi-Fi)

If any one of these is false, the attack breaks. Number 4 is the hardest part for an attacker. Recovering the key is trivial.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼

Upgrade to Go 1.27.3 or 1.26.10 and REBUILD your binaries. Go compiles the fix into your program, so updating Go on your laptop protects nothing that's already deployed.
Rebuild container images so they pick up fresh ca-certificates
Run 𝚐𝚘𝚟𝚞𝚕𝚗𝚌𝚑𝚎𝚌𝚔 ./... to see if you're affected
On Go 1.25 or older? It gets no fix. This is a good reason to upgrade.

https://pkg.go.dev/vuln/GO-2026-6809

reconD v0.5.0 - Linux Packaging

Ercross — Wed, 21 Oct 2026 12:19:52 +0000

In case you missed the dev.to's introduction post to reconD, here you go
https://dev.to/ercross/recond-pull-based-deployments-for-one-server-without-a-platform-1jjb

New in v0.5.0: install it like any other system service

Until now, using reconD meant cloning the repo, building it with Go, and writing your own systemd unit.
With the new [v0.5.0] release (https://github.com/ercross/reconD/releases/tag/v0.5.0), every release ships .deb and .rpm packages for amd64 and arm64.

On Debian or Ubuntu:

VERSION=0.5.0
ARCH=amd64   # or arm64
curl -fsSLO "https://github.com/ercross/reconD/releases/download/v${VERSION}/recond_${VERSION}_${ARCH}.deb"
curl -fsSLO "https://github.com/ercross/reconD/releases/download/v${VERSION}/checksums.txt"
sha256sum --ignore-missing -c checksums.txt
sudo apt install "./recond_${VERSION}_${ARCH}.deb"

On Fedora, RHEL-compatible, or openSUSE, it's the same with recond-${VERSION}-1.x86_64.rpm and dnf install or zypper install.

Then:

sudo cp /etc/recond/config.yaml.example /etc/recond/config.yaml
sudoedit /etc/recond/config.yaml
sudo systemctl enable --now recond
sudo journalctl -u recond -f

The packages behave the way you'd expect from a system service:

Install puts the binary at /usr/bin/recond, adds a systemd unit, an example config, and /var/lib/recond. It doesn't start anything until you've written a config, and it prints those setup steps if you haven't.
Upgrade restarts the service on the new binary if it was running, and leaves it stopped if it wasn't. Your config and state aren't touched.
Remove stops and disables the service and keeps your config and state. On Debian, apt purge removes those too.

CI tests all of this on every pull request, including upgrading a running service from the previous release, and a release can't be published unless those tests pass.

Heads-up if you already run reconD: this release is breaking. The default paths moved from /etc/reconD and /var/lib/reconD to lowercase /etc/recond and /var/lib/recond, and the binary is now recond. The changelog has the migration steps.

ReconD: pull-based deployments for one server, without a platform

Ercross — Wed, 21 Oct 2026 12:08:58 +0000

The simple use case is this:

You have a machine
And a containerized app running on that machine.
Your CI pipeline already builds and publishes images.
You do not want a full container orchestrator for this workload, but you also do not want to SSH into the box and manually run deploy scripts every time a new image is ready.

That is the space reconD is designed for. reconD is a single-host deployment reconciliation agent. To put it simply, it watches your deployment metadata and deploys the latest version of your app.

A typical workflow for a sample app called my-app

Your CI publishes:

a container image to GHCR
a GitHub Release
a deployment-metadata.json file that specifies the image, its immutable manifest digest, and the git SHA.

On your virtual machine, reconD periodically asks: "What is the latest desired deployment for dev-my-app or staging-my-app?"

Then it checks: "Is this server already running that digest?" If not, it runs the command you configured:

sh make redeploy-app

That command can be a shell script, a Make target, a Docker command, or something that wraps Docker Compose.

reconD does not try to understand your whole app topology. It does not manage networking, volumes, secrets, scaling, scheduling, ingress, or clusters. That narrowness is intentional. It only owns the reconciliation loop:

Fetch desired deployment metadata.
Compare desired digest with local state.
Inspect the runtime container.
Apply an optional strategy, such as updating an env file with the new image tag.
Run your deploy command.
Wait for health.
Commit deployment state.
Roll back if the deployment fails.
Notify you of deployment status

reconD just keeps asking: "Is this host running the latest version of your app yet?" And if the answer is no, it runs the one command you already trust. It is not Kubernetes. It is not trying to become Kubernetes. It is a small reconciliation loop for single-host deployments, built for the cases where that is exactly enough.
That's the whole model. The server pulls; nothing pushes into it. No inbound SSH from CI, no deploy keys in your pipeline, no open webhook port.

What reconD deliberately doesn't do

reconD doesn't know what Compose is. It runs your command. That command can be docker compose up -d, docker run ..., make redeploy, or a script that runs migrations first. All the knowledge about how to deploy on this particular machine stays in that command, where you can read and test it.

That keeps reconD small. It doesn't manage networks, volumes, secrets, ingress, scaling, or clusters. If a problem needs to understand your app's topology, it belongs in your deploy command, not in the agent.

Failure handling

The interesting part of deployment automation isn't the happy path. It's what happens with a bad release.

Bounded retries. Forward deployments and rollbacks retry with exponential backoff and jitter, up to limits you set:

deployment_retry:
  max_retry_forward_deployment: 3
  max_retry_rollback: 2

It remembers failures. Without this, a bad image gives you an endless loop: deploy, fail the health check, roll back, next poll, deploy the same bad image again. reconD records the failed digest in its state file and doesn't try it again automatically. If the rollback succeeds, your service is back up, but the failed version stays blocked. Pushing a newer release unblocks deployment.

It survives restarts. The current deployment, the previous one (the rollback target), and any terminal failure live in one JSON state file on disk. Restart the agent, or the host, and it picks up where it left off.

You can also point reconD at a Slack webhook to hear when a deployment starts, succeeds, or fails.

Try it

If you run apps on a single server and want deployments that are pulled, health-checked, and can roll back, without adopting a platform, give it a try:

github.com/ercross/reconD

Issues, ideas, and "this broke on my distro" reports are all welcome.