Octeth v6.0.0 Now Available! See What's New

Octeth v6.0.0: A Release That Mostly Says No

Octeth v6.0.0 is a security release. We audited every command in the API and fixed everything the audit found, which means most of this release consists of Octeth refusing requests it used to accept. We also found that Octeth had been recording its own address instead of your visitors'. Here is what changed and what it means for you.

Octeth Team

Email Marketing Experts

8 min read
Octeth v6.0.0: A Release That Mostly Says No

Octeth v6.0.0 is out today, and it is a security release.

Over the last two weeks we audited the entire API surface of Octeth, every command and every endpoint that accepts a request, and we fixed everything the audit found. That was the only thing we committed to for this sprint. Two hundred and twenty-four commits, seventy-six pull requests and fifty-seven issues later, it is done.

I have been building email software since 1999, and I have learned to be suspicious of release posts that announce security work in a sentence and then move quickly to the new features. So I am going to do this the other way round.

What The Audit Covered

The findings fell into five areas.

Credential handling. Several API responses were returning more than they should. Password hashes, auth tokens, two-factor secrets and API keys no longer appear in any of them. We replaced the random number generator used for credentials, closed a session fixation issue, made two-factor codes single use, and gave password-reset links a one-hour expiry.

Tenant isolation. Octeth is multi-tenant. Many of our customers run it as a platform for their own clients, which means one account on an installation must never be able to read or change another account's data. We found places where the API trusted an id in the request instead of checking who owned it. Those checks now happen on the way in and again every time a stored id is read.

Outbound requests. A few features make Octeth fetch a URL on your behalf: importing subscribers from a URL, webhook callbacks, the journey webhook action. Those now accept only ordinary web addresses and refuse anything pointing back into your own network.

Input validation. Ids that reach database queries are validated before they get there, segment rules are checked when they are saved, and a few places that accepted more than they needed to now accept less.

The admin area. The Authorized IP Addresses setting is now enforced on every admin request, not only when the login page renders. The admin "remember me" cookie is harder to misuse, and restricted sub-administrators are held to the user groups they are allowed to manage across the API as well as on screen.

A small number of these were serious. One was reachable from the public internet with no credential at all. The public changelog lists every one of them, in plain terms, and I would rather you read that list than a softened version from me. We have no indication that any of them was exploited.

Why Most Of This Release Is A Refusal

Here is the thing about a security release that I want to be direct about.

Almost every fix in v6.0.0 takes the form of Octeth saying no to something it used to say yes to. A request with an id that belongs to another account. A webhook URL that points somewhere it should not. An API call without a credential that should always have needed one.

Nothing that succeeded before comes back in a different shape. If a call works today and is still allowed, it returns exactly what it returned before. But an integration that was, knowingly or not, relying on one of those old yeses will now get a refusal, and from the integration's point of view that looks like breakage.

This release can change the behaviour of code you wrote against our API. Every newly refused request is listed on the behavior changes page, so if you have integrations, that page is the one to read.

We Were Recording The Wrong Address

This is the part of the release I find hardest to write about.

Octeth records the IP address of the people who interact with it: when someone subscribes, confirms, unsubscribes, opens an email, clicks a link, or signs in to the admin area. On a standard installation, Octeth had been recording the address of its own front-end container instead. Not sometimes. For every request, on every install.

The front end was passing the real address along correctly the whole time. Octeth was discarding it, because the address it was checking against did not match how the bundled containers actually talk to each other. It is a small mismatch with a long reach.

Here is what it touched:

  • The admin IP allow-list was comparing everyone against the container, so it was either letting everybody in or nobody.
  • Per-IP limits were counting all of your traffic as a single visitor.
  • Open and click geography was attributing everything to one location.
  • Subscription, opt-in and unsubscription IP records hold the container's address instead of the subscriber's.

From v6.0.0, Octeth records your visitors' real addresses. There is nothing to configure.

I want to be clear about the last item on that list, because it cannot be fixed. Those IP records exist so you can show that a specific person subscribed from a specific address. For records created before this upgrade, the real address was never written anywhere, so there is nothing to recover it from. Records created from today onward are correct. The older ones are not, and no migration can change that. If you have ever relied on those columns as consent evidence, you should know that.

Your geographic reports will also start to look different. That is not a change in your audience. Until now, opens and clicks were being attributed to a single location, so the reports now show where your audience actually is.

Rate Limits Now Do What They Said

Every API command in Octeth has always declared a request budget, usually 100 requests a minute. Until this release, only six commands actually applied theirs.

From v6.0.0 the budget is enforced on every command. A call over its budget gets an HTTP 429 response telling it how long to wait. Octeth's own screens are not counted, so your team will not notice anything. An integration that sends a burst of calls to one command might.

This is another case of the product finally doing what its documentation already said it did. I would rather close that gap than keep a number on paper that nothing enforces.

Bulk SMS, Through The API

There is one substantial new capability in this release, and it arrived because it happened to be ready inside the window.

Octeth can now send bulk SMS campaigns to lists and segments, including to contacts who have a phone number and no email address at all. That last part matters more than it sounds. Until now, a contact in Octeth was an email address. If most of your audience is reachable by phone and not by email, they did not fit.

It comes with SMS templates, per-list SMS settings, a cost estimate before you send, delivery reports, inbound replies with automatic opt-out handling, frequency caps, forbidden-word checks, campaign-level reporting and a new segment rule that targets contacts by their SMS activity.

It is available through the API and in the admin area. The SMS campaign screens for your customers in the new user interface are not part of this release. I would rather ship the engine when it is ready and the screens when they are ready than hold one back for the other.

Two Things To Check Before You Upgrade

If you have filled in Authorized IP Addresses in the admin area, check it before upgrading: it is now enforced on every admin request and now sees real addresses, so a list containing an internal container address (one starting with 192.168.99.) will lock your administrators out. If you have API integrations that send bursts of calls, check that they can handle a rate-limit response. The changelog covers both, along with everything else in this release.

A Note On What This Release Is

Nothing in v6.0.0 will make a demo more impressive. Most of it is invisible when it works, and the visible parts are refusals.

But the question a self-hosted platform has to answer, before any feature question, is whether you can trust it with your clients' data and your sending reputation. A full audit of the API surface, with every finding fixed and every behaviour change written down, is part of how we try to earn that. Telling you plainly about the addresses we got wrong for years is another.

Next release is October 9th, two weeks from today.

Already an Octeth client? Log in to the Octeth Client Area to download v6.0.0.

Want to see what running your own email platform looks like? Tell us about your setup through the contact form at octeth.com/demo/ and we will show you.

Share this article