UBUNTU-CVE-2026-126068: Medium severity ubuntu/rails vulnerability
Action Mailbox routes incoming emails to controller-like mailboxes for processing in Rails. Prior to 8.1.4.1 and 8.0.5.2, the Action Mailbox Mailgun ingress authenticates a request with an HMAC of the timestamp and token parameters concatenated without a separator, and ActionMailbox::Ingresses::Mailgun::InboundEmailsController::Authenticator#recent? rejects only timestamps more than 2 minutes in the past. Because the signature does not fix the boundary between the two values, a captured signed request can be presented with a timestamp far in the future, which the ingress then accepts indefinitely. An attacker who obtains one signed Mailgun webhook request, but not the signing key, could submit arbitrary inbound email that Action Mailbox processes as genuine, possibly leading to forged messages attributed to the sender of the attacker's choosing. Applications that receive inbound email through the Action Mailbox Mailgun ingress are affected. This issue is fixed in versions 8.1.4.1 and 8.0.5.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Action Mailboxto a version that resolves this vulnerability.Fixed in 8.1.4.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications that receive inbound email through the Action Mailbox Mailgun ingress are affected. The provided information does not indicate that other Action Mailbox ingress providers are affected.
What does an attacker need to exploit it?
An attacker needs to obtain a single signed Mailgun webhook request; they do not need the Mailgun signing key. They can then alter the ambiguous timestamp and token boundary to create a request with a far-future timestamp that remains accepted.
What is the impact of a successful exploit?
The attacker can submit arbitrary inbound email that Action Mailbox processes as genuine. This could result in forged messages being attributed to a sender chosen by the attacker.
Which versions contain the fix?
The issue is fixed in Rails 8.1.4.1 and 8.0.5.2.