If your hosting store is still running a Paymenter release older than v1.5.8, you're missing security fixes from five separate releases shipped over the course of 2026, including one that let logged-in customers bypass your plan limits at checkout and one that needed no login at all. The most severe one carried a CVSS score of 8.5.
The short answer: update to v1.5.8, the current latest release. The rest of this guide walks through what each 2026 release actually fixed, why it matters for a business selling hosting, and how to update without breaking your store.
Why this matters more for a hosting store than for a typical web app
Paymenter isn't just a content site with a login form, it's the billing layer that decides how much CPU, RAM and storage a customer's payment actually buys, and it holds your payment gateway credentials. That's exactly the surface the 2026 advisories touched: plan limits at checkout, store credit balances, refund amounts, and gateway secrets. A bug in a typical web app's comment form is embarrassing; a bug that lets a customer provision a bigger server than they paid for, or double-spend their credit balance across several invoices, is a direct hit to revenue, and it can go unnoticed for a long time if nobody is specifically checking for it. Unlike a defaced page or a broken feature, none of these bugs announce themselves: a customer quietly getting more resources than they paid for, or paying two invoices with one credit balance, looks like normal store activity until someone reconciles the numbers.
What changed in v1.5.8
Paymenter v1.5.8, released 20 August 2026, is the current latest version. Alongside a fix for advisory GHSA-hf99-p45q-qfmf, it encrypts gateway credential settings at rest, meaning API keys and secrets for your payment gateways are no longer stored as plain text in the database, so a leaked database backup or a compromised server no longer hands over live payment credentials directly. It also fixes a cron bug that was deleting notification records instead of old email logs, stops a failed invoice notification from rolling back a payment that had already been recorded, and fixes cart items pricing against the wrong currency after a cart's currency had been locked.
The five 2026 security releases
Paymenter shipped fixes for publicly tracked vulnerabilities in five separate releases this year. Here's the timeline, confirmed from the release notes and the security advisories on GitHub:
| Version | Released | Advisory | What it allowed |
|---|---|---|---|
| v1.5.0 | 9 May 2026 | CVE-2026-44583 (CVSS 5.3), CVE-2026-44585 (CVSS 5.4), CVE-2026-44584 (CVSS 4.3), all Medium | A blind SSRF in the PayPal gateway module that needed no login at all; access to another customer's service by changing the service reference in a request; and an e-mail address that stayed marked as verified after it was changed. |
| v1.5.1 | 19 May 2026 | CVE-2026-47198 (CVSS 8.5, High) | URL parameter injection at checkout let a logged-in customer inject unvalidated configuration keys (CPU, RAM, storage) that overrode admin-set limits during provisioning, bypassing plan restrictions entirely. |
| v1.5.5 | 12 Jun 2026 | CVE-2026-55219 (CVSS 5.3, Medium) | A race condition in payWithCredit(): a pessimistic row lock was applied outside an active database transaction, so concurrent payment requests could read the same store-credit balance and double-spend it across invoices. |
| v1.5.7 | 25 Jul 2026 | GHSA-5gmm-hjfj-8ff7 and GHSA-prhx-9q2h-ph2x | A similar race condition, this time in service downgrades, that could let a customer trigger multiple refunds for a single downgrade. |
| v1.5.8 | 20 Aug 2026 | GHSA-hf99-p45q-qfmf | Gateway credential settings were stored unencrypted at rest; anyone with database access (a leaked backup, a compromised host account) could read live payment gateway secrets directly. |
The pattern across most of these fixes is the same: a request-handling flaw that let an ordinary logged-in customer manipulate pricing, plan limits, store credit or someone else's service in their own favour. None of them needed admin access, and the PayPal SSRF fixed in v1.5.0 needed no account at all. If you're on anything earlier than v1.5.0, every issue in this table applies to your store at once.
What else shipped alongside the security fixes
Each of these releases also carried smaller fixes worth knowing about if you're planning the jump. v1.5.1 corrected service recalculation currency handling, fixed OAuth account creation and updates, and added rate limiting to the coupon endpoint. v1.5.5 stopped a 500 error when a cancellation reason exceeded 255 characters and fixed a checkout coupon object access bug. v1.5.7 added rate limiting to ticket replies, hardened plan validation, strengthened Stripe webhook validation, and fixed an admin service-cancellation error that occurred when the underlying product had been deleted. None of these are security issues on their own, but they're a reason to read the full release notes rather than just the advisory line before you update.
How to update safely
Paymenter's own update documentation covers three paths, and its guidance is worth following as written: check that your installed themes and extensions are compatible with the target version before you start.
Automatic update
From your Paymenter directory, run:
cd /var/www/paymenter
php artisan app:upgradeManual update
- Put the site into maintenance mode:
php artisan down - Download and extract the latest release:
curl -L https://github.com/paymenter/paymenter/releases/latest/download/paymenter.tar.gz | tar -xz - Update any installed extensions or themes to their compatible versions
- Fix permissions:
chmod -R 755 storage/* bootstrap/cache/ - Run database migrations:
php artisan migrate --force --seed - Clear caches:
php artisan optimize:clear - Set web server ownership:
chown -R www-data:www-data /var/www/paymenter/* - Bring the site back up:
php artisan up
Docker
docker compose down -v
docker compose pull
docker compose up -d --force-recreate
docker compose exec paymenter php artisan app:settings:change theme defaultIf you installed Paymenter following our own install guide, the manual steps above map directly onto that setup. Either way, treat the update like any other production change: take a database backup first, and do it during low-traffic hours in case a theme or extension needs adjusting afterwards.
Beyond patching: reducing your own exposure
Staying current with releases closes the vulnerabilities Paymenter's maintainers find and fix, but two things are still worth doing on top of that. First, require two-factor authentication for staff and admin accounts. We cover the setup on Pterodactyl in this guide. None of the 2026 advisories needed admin credentials, but a compromised admin account is a far bigger blast radius than any of them.
Second, the checkout and account-abuse issues above are the kind of thing Security Addon for Paymenter ($5.99, 59 purchases, 5.0/5 from 6 reviews) is built to catch on the account side: it can block specific users, IPs and VPN connections and flag alt accounts, which is complementary to, not a replacement for, keeping the core application patched.
It's also worth knowing that php artisan down shows Laravel's bare default maintenance page during every manual update. If you'd rather your customers see a branded page with your own message while you patch, Maintenance Mode ($5.99, 2 purchases, 5.0/5 from 1 review) lets you close the storefront on a schedule or with one button instead, which is a small thing but it looks a lot more professional than a bare framework error page during a maintenance window.
None of this replaces reading the release notes yourself. Paymenter's releases page and GitHub releases are the two places to check before you decide an update can wait, and both are worth bookmarking or watching if you run a store on Paymenter long-term. Paymenter is under active development with new point releases arriving roughly every few weeks, so treating updates as a routine, scheduled task rather than something you get to eventually is the difference between closing these gaps within days and leaving your store exposed for months.