A critical flaw in the Eclipse Foundation's otterdog web application lets unauthenticated attackers run code on the server hosting it, after the vulnerability was published on Monday, 9 November 2026.

The flaw, tracked as CVE-2026-123870, is rated critical with a score of 9.5. It affects otterdog versions from 0.9.0 up to, but not including, 1.3.2, and is fixed in version 1.3.2.

How the flaw works

According to the US National Vulnerability Database (NVD), the otterdog webapp builds a format string from the JSON body of incoming GitHub webhook requests and then evaluates it using Python's eval() function, which runs text as code.

That alone would be dangerous, but the flaw is worse. When the GITHUB_WEBHOOK_SECRET setting is unset or empty, which is the code's default, the check that verifies the webhook's HMAC signature is skipped entirely. GitHub webhooks are normally signed with a shared secret so the receiver can tell a genuine GitHub request from a forgery; with no secret configured, there is no check at all.

An unauthenticated attacker on the network can therefore send a crafted HTTP POST request containing malicious Python code in the JSON payload. Because the signature check is bypassed, the application passes the attacker's input straight to eval(), executing arbitrary Python code on the webapp host.

Why this combination is so severe

The flaw is classed as CWE-95, improper neutralisation of directives in dynamically evaluated code, commonly known as eval injection. It combines two separate mistakes: running attacker-influenced data as code, and treating a missing security secret as a reason to skip verification rather than refuse the request.

Either mistake on its own would be serious. Together, they mean that any otterdog installation reachable from the internet, and running without a webhook secret, can be taken over by anyone who can send it a web request. No login, no account and no user interaction are needed.

Code execution on the host can lead to stolen credentials, tampering with the repositories otterdog manages, and a foothold for further attacks inside the network where the server runs.

What otterdog users should do

Users should upgrade to otterdog 1.3.2 or later, which fixes the flaw, and set GITHUB_WEBHOOK_SECRET to a strong, randomly generated value in every deployment. The secret must be the same value configured in GitHub, so that only genuinely signed webhook deliveries are accepted.

Administrators should also check whether their installation was ever reachable without a secret configured, and review logs for unexpected webhook requests or unfamiliar processes on the host. If there is any doubt, credentials stored on or reachable from the server should be rotated.

As a general rule, a webhook endpoint should never be left open to the internet without signature verification, and a security setting that is empty should fail closed, refusing requests, rather than silently disabling the check. The flaw was published by the Eclipse Foundation, which assigned the CVE, and recorded in the NVD on 9 November 2026.