A payment method security release, and why we backported it to every version
The short version
We kindly advice you to update Hyvä Checkout today. We resolved a high-severity security issue in Hyvä Checkout, that allows bypassing payment method availability checks. The fix is available now to all of our customers, without additional cost. Even without an active support subscription.
Be assured: Regular checkout flow is unaffected and secure, no customer data is being leaked, no store was taken offline, and there is no PCI DSS impact.
The gap only opened for a request that did not go through our checkout at all, where our end-of-checkout validation was bypassed. This means an order could be placed using a payment method not available under regular circumstanced, but it does not affect the order state or payment capturing.
The fix ships in 1.3.12, and we have backported it to every supported version going back to 1.0.7, first released in June 2023. That means you can get a fixed version of the checkout you already run, without doing a larger upgrade. The fastest route for most stores is to add .1 to your current version, so 1.2.5 becomes 1.2.5.1, and composer will pull the appropriate fixed version. The rest of this post explains what happened and how to protect your store.
What the issue was
Hyvä Checkout works out which payment methods are available for a given cart and store setup. Our checkout does check this when an order is placed, which is why a normal shopper could not use an invalid method. The weak spot was earlier in the process: when the chosen method was first saved, that save did not rerun the availability check on its own. Inside our checkout that did not matter, because the payment method was validated again before the order was placed.
It only mattered if the checkout was completed without going through Hyvä Checkout, and so never reached the final validation. In that narrow case a method our checkout would have rejected could still end up on a placed order. We are keeping the exact path out of this post, and will come back to the mechanics in a later write-up once stores have updated.
In plain terms: through the normal checkout the store was protected, but there was a way bypassing the checkout to place an order using a payment method the store had ruled out. We rated this issue high severity.
To be clear about what this was and was not: no customer data was leaked, there is no PCI DSS impact, and it did not take a store offline. What it allowed was orders be recorded as placed and fulfillable without a valid payment behind it. That is worth treating seriously, which is why we resolved it for the current version and backported the fix to almost all previous versions.
We are keeping the technical specifics short for now. A full write-up with the root cause and the fix will follow once stores have had time to update. Publishing a step-by-step breakdown before everyone is patched would only make it easier to abuse in the meantime.
Why it was there in the first place
The root cause says something about how Hyvä Checkout is built. Hyvä Checkout is deliberately flexible about the order of the checkout steps, including putting payment first, before a shipping address has even been entered. That flexibility is a feature people choose Hyvä for. The path that made it possible did not enforce the availability check on the server. The fix adds that guard while keeping the flexibility.
How we fixed it
Teun, an independent security researcher, reported this to us responsibly through our disclosure process. From the first report to the shipped fix we worked directly with Teun to confirm the issue, agree on its severity, and check the fix. That back and forth made the outcome better.
The fix routes the payment method selection through Magento's own payment method management API, which enforces the availability check on the server before the method is accepted. A method that is not available for the current cart is now rejected, and the shopper sees a clear message instead of a silently accepted invalid choice. The checkout stays as flexible as it was.
Making sure it stays fixed
A fix is only as good as your confidence that it stays fixed. We maintain an automated end-to-end test suite for Hyvä Checkout, built with Playwright, that exercises the checkout across versions, and we verified the fix against it. We run it against the current release and against older versions too, to confirm the backports hold up the same way. We will say more about how we approach testing in the follow-up post.
How the backport works, and how it reaches everyone
This is the first time we have rolled out a security fix this way, and it is worth explaining, because it means you do not have to take on a larger upgrade just to get protected.
For every affected version we published a dedicated security release that adds a fourth number to the version tag: a .1 on the end. For example, if a store pins the Hyvä Checkout version to 1.2.5, the patched release is 1.2.5.1. It contains the exact version plus this one fix and nothing else, so applying it changes no other behaviour. For most stores you get it by adding .1 to the tag you already use, or by changing your constraint to ~1.2.5 and running composer update.
We released updates for the whole supported history, back to version 1.0.7, which first shipped in June 2023, more than three years ago. So even if you deliberately pinned your store to an older version and stayed there, there is a matching x.y.z.1 release waiting for you. You do not need to jump to the latest line to be safe.
You can install this with the Checkout licence key you already have. We dated each backported release to match the original release it patches, so it is inside the time window for releases you have access to with your existing key. As a Hyvä Checkout customer, the security patch for your version is available to you now, with no extra costs. Keeping customers safe matters to us, whether or, not you are on an active plan today. (If you would like to come back for new features and the latest releases, you are welcome to reactivate your subscription at any time, but you do not need to for this fix.)
We will keep doing this. If another fix is needed later, we will create a new release with a .2 version suffix, then .3, and so on. This provides a small, safe step you can take to stay protected without a larger upgrade.
Backporting one fix cleanly across an entire release history, and checking each one, is a lot of careful, repetitive work. That cost is exactly why a project would normally take the pragmatic route: patch the latest version, maybe the most recent release line, and leave older versions behind. We used AI to do the heavy lifting of applying and verifying the fix across every version, which made creating all these backports possible.
How to protect your store
Pick whichever fits how you manage your dependencies:
- Recommended: upgrade to
1.3.12. - Staying on an older line: upgrade to the nearest
x.y.z.1backport tag for your version, for example1.2.5to1.2.5.1. - Automatic: change your constraint to
~x.y.zand runcomposer updateto receive the right backport automatically. - Manual patch: if you need to apply the fix immediately on a customised install, a standalone patch file is available on request. Hyvä Checkout is source-available rather than open source, so we share the patch directly through our Slack channels rather than posting it publicly.
Full upgrade and patch details are in the Hyvä Checkout security changelog.
Features on a schedule, security when it is ready
It is worth explaining how this fits our release rhythm, because the two are deliberately separate.
New features ship on a triannual schedule. You get a predictable rhythm to plan around: something to test against, schedule work for, and upgrade on your own terms.
Security fixes do not wait for the next trimester. They go out when they are ready, on their own schedule. This fix is a good example: it did not ride along with a tertial release, it shipped on its own the moment it was tested and ready. Features you can plan for, protection you do not have to wait for. Neither holds up the other.
Keeping an eye on security updates
If you are a security officer, a merchant, or an agency looking after Hyvä stores, our security advisories page is the one place to check. It lists every critical and high-severity fix across all Hyvä products, with a link through to the details of each.
There is a "Last Updated" date at the top of that page. Bookmark it and watch that date: when it changes, there is new security information worth a look. It is a simple, reliable way to audit whether you are current without having to follow every individual release.
If you would rather have updates come to you, join our community Slack and follow the #update-notifications channel. We post every product release there, security patches included, so you hear about a fix as it ships rather than having to check.
Working with researchers
Coordinated disclosure is how security is meant to work, and we want it to be a good experience for the researchers who choose to work with us. Teun reported this carefully and stayed with us through the fix and the rollout, and we thank Teun for that.
If you have found a security issue in a Hyvä product, we would like to hear from you. You can see how to report it, how to reach the team, and the researchers we have recognised so far on our security and compliance page. Every report makes Hyvä safer for the merchants who rely on it, and we do not take that lightly.
