# A Sustainable and Eco-Responsible Vision Source: https://blog.onetsolutions.net/en/a-sustainable-and-eco-responsible-vision How OnetSolutions promotes eco-responsibility through server recycling, component reuse, and donations to charitable programs. A Sustainable and Eco-Responsible Vision *Published on June 28, 2023* In an ever-changing technology landscape where data plays a central role, it is essential to promote eco-responsible practices. At OnetSolutions, we are proud to embody this sustainable vision. In this article we walk through the concrete initiatives we have around server recycling, component reuse, and refurbishment — proof of our commitment to eco-responsibility and our contribution to a greener future. As you might guess, eco-responsibility is a top priority at OnetSolutions. ## Component reuse ### Extending equipment life for a sustainable approach Rather than discarding outdated servers, we look for ways to get the most out of them. When evaluating end-of-life servers, we carefully identify which components can still be reused. Components in good shape are extracted, tested, and put back into our own infrastructure — extending their useful life. This approach lets us significantly reduce e-waste by maximising the use of available resources. By giving retired servers a new purpose, we help reduce demand for new equipment and support a circular, responsible economy. ## Donations ### A second life and support for charitable programs We can also donate functional servers to non-profit organisations. These servers can then support educational projects, training programs, or community initiatives — giving the equipment a meaningful second life. We strongly believe in the value of reuse and donation as part of our eco-responsible approach. By reusing components and donating equipment, we help cut e-waste, promote a circular economy, and support equitable access to technology resources. *** Eco-responsibility is at the heart of OnetSolutions' vision for the future of data centres. Through our recycling, component reuse and refurbishment initiatives, we demonstrate our commitment to a sustainable and responsible approach. By adopting these practices, we help protect the environment by cutting e-waste and minimising our carbon footprint. At OnetSolutions, we are aware of our role as a VPS provider and the impact we can have on the environment. That is why we work hard to integrate eco-responsible solutions across our business. We work closely with our partners and suppliers to promote sustainable practices and encourage innovation in environmentally friendly technologies. We are proud to deliver quality service to our customers while keeping our ecological footprint as small as possible. By choosing OnetSolutions, our customers know they are also contributing to environmental preservation. In a world where natural resources are increasingly limited, technology companies must adopt an eco-responsible approach. At OnetSolutions, we are determined to play a leading role in this transition to a more sustainable future. To wrap up: our commitment to eco-responsibility shows up in our practices around server recycling, component reuse, and refurbishment. We strongly believe that sustainability and environmental responsibility are essential to shaping a better future. At OnetSolutions, we keep innovating and looking for new ways to reduce our environmental impact while delivering high-quality service to our customers. # AlmaLinux 9: Optimal Performance and Stability Source: https://blog.onetsolutions.net/en/almalinux-9-performance-and-stability AlmaLinux 9, a 100% compatible alternative to CentOS, is now available on our VPS — bringing optimal performance, stability, and enhanced security. AlmaLinux 9: Optimal Performance and Stability *Published on May 13, 2023* We are happy to announce that AlmaLinux 9 — the latest Linux distribution developed as a 100% compatible, reliable and secure alternative to CentOS — is now available. AlmaLinux 9 delivers optimal performance and stability for your servers, ensuring a top-tier hosting experience. ## A reliable and secure alternative to CentOS After the recent changes to CentOS, the Linux community looked for a solid alternative to keep enjoying a stable, trusted Linux distribution. That is where AlmaLinux comes in — a distribution developed by CloudLinux in collaboration with the Linux community. AlmaLinux 9 is built from the Red Hat Enterprise Linux (RHEL) source code and is 100% compatible with existing CentOS applications and tools. AlmaLinux 9 has been designed to deliver optimal performance and stability. Thanks to its Linux kernel and optimised system components, AlmaLinux 9 can handle intensive workloads and ensure high availability. You get the reliability and robustness of an enterprise-grade operating system, without the associated costs. ### The benefits of AlmaLinux 9 * Optimal performance for your servers: by choosing AlmaLinux 9 at OnetSolutions, you get top-tier performance for your servers. Our state-of-the-art infrastructure combined with AlmaLinux 9 delivers exceptional stability and speed, ensuring fast response times for your applications and websites. * Full compatibility with CentOS applications: if you are currently running CentOS applications and tools, the move to AlmaLinux 9 at OnetSolutions will be seamless. AlmaLinux 9 is 100% compatible with existing CentOS applications and configurations, which means you can migrate without worry and keep the same functionality and performance. * Enhanced security to protect your data: data security is a top priority at OnetSolutions. AlmaLinux 9 benefits from regular security updates and bug fixes, ensuring the protection of your sensitive data. With AlmaLinux 9 available at OnetSolutions, you get a reliable, performant and secure operating system for your servers. Enjoy the optimal performance, full CentOS compatibility, and enhanced security AlmaLinux 9 brings to our VPS. # The ARVE Backdoor (CVE-2026-18072): When the Supply Chain Is the Vulnerability Source: https://blog.onetsolutions.net/en/arve-backdoor-cve-2026-18072 A WordPress plugin with 20,000 installs shipped a hardcoded admin backdoor. What happened, how to check your sites, and what it changes about plugin trust. *Published on August 8, 2026* **CVE-2026-18072, CVSS 9.8.** Version 10.8.7 of the Advanced Responsive Video Embedder plugin contains a deliberate backdoor. There is no fixed version: WordPress.org pulled the plugin. If you have it installed, remove it. ## This is not a bug Every other advisory we publish describes a mistake — a missing check, a bad assumption, an off-by-one. This one describes intent. On 28 July 2026, version 10.8.7 of the Advanced Responsive Video Embedder plugin — around 20,000 active installations — shipped with a function named `_arve_uc_init()`, hooked onto WordPress's `init` action at priority 1, so it runs before almost everything else. The function reads a token from the `_wplogin` or `_wpm` request parameter and compares it against a SHA-256 hash hardcoded in the plugin source. If they match, the request is authenticated as any existing administrator account the attacker names. No nonce verification. No capability check. No password. A hash embedded in source code that anyone can download is not a secret. It is a universal credential, valid on every site running that version. The classification says it plainly: CWE-506, embedded malicious code. ## What made it survivable Two things kept this from being a catastrophe. **It was caught in under two hours.** Wordfence's automated analysis flagged the malicious code on 28 July, less than two hours after it was published. The plugin repository was closed for downloads the same day. **Auto-updates had not yet propagated it.** The WordPress.org team confirmed the malicious release had not been broadly distributed through automatic updates before the takedown. Most of those 20,000 sites never received 10.8.7. Note the irony: automatic updates, the control that would normally have protected you, is the exact channel a supply-chain compromise travels down. It was slowness that limited the damage here. ## Sizing your exposure | Situation | Exposure | Action | | - | - | - | | Plugin never installed | None | Nothing to do | | Plugin installed, version below 10.8.7 | None from this backdoor | Remove or replace it — the plugin is no longer maintained on WordPress.org | | Plugin installed at **10.8.7** | **Critical** | Assume compromise: remove, audit, rotate credentials | | Plugin installed, version unknown | Unknown | Check now, treat as 10.8.7 until proven otherwise | ## Checking your sites Find out whether the plugin is present, and at which version: ```bash theme={null} # From the site root, with WP-CLI wp plugin get advanced-responsive-video-embedder --field=version # Across several sites, from the directory holding them for d in /var/www/*/; do printf "%s " "$d" wp --path="$d" plugin get advanced-responsive-video-embedder --field=version 2>/dev/null || echo "absent" done ``` Without WP-CLI, the version is in the plugin header: ```bash theme={null} grep -i "^ \* Version:" wp-content/plugins/advanced-responsive-video-embedder/*.php ``` If the version is 10.8.7, look for the backdoor itself before removing anything — you want to know what you are dealing with: ```bash theme={null} # The backdoor function and its parameter names grep -rn "_arve_uc_init\|_wplogin\|_wpm" wp-content/plugins/advanced-responsive-video-embedder/ ``` Then check your access logs for anyone who used it: ```bash theme={null} # Requests carrying the backdoor parameters grep -E "_wplogin=|_wpm=" /var/log/nginx/access.log | head -50 ``` Any hit there is not a scan artefact. Those parameter names mean nothing to any other piece of software. ## If the backdoor was present Removing the plugin closes the door. It tells you nothing about who came through it first. Work through it in this order: 1. **Remove the plugin.** `wp plugin deactivate advanced-responsive-video-embedder && wp plugin delete advanced-responsive-video-embedder` 2. **Audit administrator accounts**, including creation dates and email addresses. The backdoor authenticates as an *existing* admin, so a rogue account is not guaranteed — but attackers commonly add one for persistence. 3. **Look for files added or modified since 28 July**, particularly PHP under `wp-content`. 4. **Rotate everything**: administrator passwords, application passwords, API keys, database credentials, and any secret stored in `wp-config.php`. Regenerate the salts while you are there. 5. **Force-logout every session** so a stolen cookie stops working: `wp user session destroy --all --all-users` If step 3 turns up anything you cannot account for, restore from a backup predating 28 July rather than cleaning in place. ## What this changes about plugin trust The uncomfortable conclusion is that reviewing a plugin's code once tells you about the version you reviewed, not the version you will receive next Tuesday. Trust in a plugin is trust in whoever holds commit access to it — indefinitely, and usually invisibly. That does not make plugins unusable. It makes a few habits worth the effort: * **Fewer plugins.** Every plugin is a standing grant of code execution to a third party. The best defence is a smaller list. * **Prefer maintained, widely-installed plugins**, with several maintainers rather than one. A single-maintainer plugin is a single account to compromise. * **Remove what is deactivated.** A deactivated plugin still sits on disk and still receives updates. It is exposure without benefit. * **Delay non-security updates by a few days** on production sites. That is exactly the window in which this backdoor was caught. * **Keep backups you have actually tested restoring.** [Shared hosting backups](https://help.onetsolutions.net/web-hosting/backup) and [VPS snapshots](https://help.onetsolutions.net/vps/snapshot) are only useful if you know the restore works. Two WordPress incidents landed within a fortnight, from opposite directions: a core flaw and a supply-chain compromise. Our [hardening checklist](/en/secure-wordpress-after-wp2shell) covers what protects against both. Want a second pair of eyes on a site hosted with us? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # Auditing and Hardening nginx on a VPS: The Routine That Beats the Next Advisory Source: https://blog.onetsolutions.net/en/audit-and-harden-nginx-on-a-vps Know what you run, shrink what is exposed, and check it in one command. A practical routine for nginx, built around what actually gets exploited. Auditing and hardening nginx on a VPS: know your version, shrink the surface, verify *Published on August 12, 2026* Two heap overflows landed in nginx's script engine within a few months of each other this year, and the second caught plenty of people who had already patched for the first. That is not a patching failure. It is an inventory failure: not knowing precisely what you run, where. This is the routine that fixes that. It takes about twenty minutes the first time, and two minutes a month afterwards. ## 1. Know what you actually run The single most useful fact, and the one most often wrong. Your package manager's opinion is not the same as the binary on disk, which is not the same as the code in memory. ```bash theme={null} # The binary nginx -v # What the package manager believes apt list --installed 2>/dev/null | grep nginx || rpm -q nginx # What is actually running, and for how long ps -eo pid,lstart,cmd | grep "[n]ginx: master" ``` If the third command shows a master process older than your last update, you installed a patch and never restarted. The old binary is still serving traffic. This is the most common gap between "patched" and "safe". `nginx -s reload` does not replace the master process. After a package upgrade, use `systemctl restart nginx`. Reload is for configuration changes, not binary changes. ## 2. Inventory every nginx you forgot about The nginx you patch is rarely the only one you run. Containers pin their own copies, and pinned tags never move on their own. ```bash theme={null} # nginx inside running containers docker ps --format '{{.Names}}' | while read -r c; do v=$(docker exec "$c" nginx -v 2>&1 | grep -o 'nginx/[0-9.]*' || true) [ -n "$v" ] && echo "$c: $v" done # Pinned tags in your compose files grep -rn "image:.*nginx" --include="*.yml" --include="*.yaml" . 2>/dev/null ``` A pinned `nginx:1.30.1` is frozen until you rebuild. If your compose files pin exact patch versions, patching is a code change and belongs in your deployment routine, not your server routine. ## 3. Shrink what is exposed Most nginx advisories affect a specific module or directive. The fewer of them you use, the fewer advisories are yours. Start by seeing what your build even includes: ```bash theme={null} # Full build configuration, including every module compiled in nginx -V 2>&1 | tr ' ' '\n' | grep -E "^--with|^--without" ``` Then check what your configuration actually reaches for. The two heap overflows this year both lived in the script engine — `map`, `rewrite`, and regex captures: ```bash theme={null} # Regex-based map blocks grep -rn "^\s*map\s" /etc/nginx/ -A 3 | grep -E "~\*?\s" # rewrite rules and regex captures grep -rnE "^\s*rewrite\s|\\\$[1-9]" /etc/nginx/ ``` This is not a reason to avoid `map` — it is a good directive. It is a reason to know whether an advisory naming it concerns you, in seconds rather than an afternoon. ## 4. Stop advertising your version nginx returns its exact version in every response header and error page by default. That turns any scan into a targeted list. ```nginx theme={null} # In the http block server_tokens off; ``` This is not a security control — it does not fix a single bug. It is a cost control: it moves you out of the trivially-enumerable set, which is where mass exploitation shops for targets. Confirm it took effect: ```bash theme={null} curl -sI https://example.com | grep -i "^server:" # expected: "Server: nginx" with no version ``` ## 5. Set the headers that cost you nothing Four headers, no downside for the vast majority of sites: ```nginx theme={null} # In the server block add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; ``` `Strict-Transport-Security` is a commitment. Once a browser has seen it, it refuses plain HTTP for your domain for the full `max-age`. Only add it when HTTPS works everywhere on the domain, including subdomains, and start with a shorter `max-age` if you are unsure. The `always` keyword matters: without it, the headers are dropped on error responses, which are exactly the ones an attacker sees most. ## 6. Put a ceiling on request size and rate Defaults are generous because nginx cannot know your application. An upload endpoint that accepts 1 GB when your largest legitimate file is 5 MB is free ammunition. ```nginx theme={null} # In the http block client_max_body_size 10m; client_body_timeout 12s; client_header_timeout 12s; # A modest rate limit zone, applied where it makes sense limit_req_zone $binary_remote_addr zone=basic:10m rate=10r/s; ``` ```nginx theme={null} # In the location that needs it — a login endpoint, for instance location /login { limit_req zone=basic burst=20 nodelay; } ``` Tune the numbers to your application rather than copying them. The point is that a number exists. ## 7. Verify, then make it routine Never reload on an untested configuration: ```bash theme={null} # Parse and validate without touching the running server sudo nginx -t # Only if that passed sudo systemctl reload nginx ``` Then reduce the whole audit to one command you can run monthly: ```bash theme={null} #!/usr/bin/env bash # nginx-audit.sh — run monthly, or after any advisory set -u echo "== version ==" nginx -v 2>&1 echo "== master process uptime ==" ps -eo lstart,cmd | grep "[n]ginx: master" || echo "not running" echo "== config validity ==" nginx -t 2>&1 | tail -2 echo "== version leak ==" grep -rq "server_tokens off" /etc/nginx/ && echo "server_tokens off" || echo "WARNING: version exposed" echo "== containers ==" docker ps --format '{{.Names}}' 2>/dev/null | while read -r c; do v=$(docker exec "$c" nginx -v 2>&1 | grep -o 'nginx/[0-9.]*' || true) [ -n "$v" ] && echo "$c: $v" done ``` ```bash theme={null} chmod +x nginx-audit.sh && ./nginx-audit.sh ``` ## What this actually buys you None of this prevents the next heap overflow in the script engine. Nothing you configure will. What it buys is the ability to answer, in under a minute, the only question an advisory really asks: **is the version I am running inside the affected range, everywhere I run it?** Teams that can answer that patch in an afternoon. Teams that cannot spend a week finding out, and usually miss a container. Two habits carry most of the weight: restart after a package upgrade, and treat pinned container tags as code that needs updating. Related reading: our advisory on the [two nginx heap overflows](/en/nginx-map-regex-cve-2026-42533) and the [enhanced VPS security guide](/en/enhanced-vps-linux-security) for the layer underneath. Questions about a server hosted with us? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # Boost Your Site Speed by Up to 400% with LiteSpeed Source: https://blog.onetsolutions.net/en/boost-your-site-speed-by-400-percent Our web hosting plans ship with LiteSpeed — an NGINX-based stack that can speed up your site (especially WordPress) by up to 400%. Boost Your Site Speed by Up to 400% with LiteSpeed *Published on May 29, 2022* At OnetSolutions, we are committed to giving you the benefits of the most advanced technologies for your website hosting. That is why our web hosting plans include LiteSpeed, a tool that optimises how fast your website loads. LiteSpeed is particularly effective for sites running on WordPress. Thanks to an optimised NGINX-based implementation, LiteSpeed can improve your site's performance by up to 400%. The result: a better user experience, faster page loads, and smoother navigation. LiteSpeed is a powerful and reliable solution for keeping your website fast — even during traffic spikes. You can be confident your site will stay quick and responsive, delivering a quality experience to your visitors. *Source: [https://www.litespeedtech.com/performance](https://www.litespeedtech.com/performance)* After setting up WAF security via ModSecurity, LiteSpeed accelerates your site by up to 12 times! *Source: [https://www.litespeedtech.com/performance](https://www.litespeedtech.com/performance)* With its plugins for WordPress, Drupal and Magento, the optimisation is impressive — delivering an unmatched number of requests per second! *Source: [https://www.litespeedtech.com/performance](https://www.litespeedtech.com/performance)* Pick OnetSolutions and benefit from our expertise in advanced technologies. We are here to help you get the most out of your website hosting and to deliver outstanding performance for your site. Don't wait — order your [website hosting](https://onetsolutions.net/hebergement-de-site-internet) at OnetSolutions [right here](https://onetsolutions.net/hebergement-de-site-internet)! # The Benefits of Caching on a VPS Source: https://blog.onetsolutions.net/en/boost-your-website-with-vps-caching How caching on a VPS speeds up page loads, lowers server load, saves bandwidth, and helps with SEO. The Benefits of Caching on a VPS *Published on October 7, 2023* If you run a website, you know how important page-load speed is. A fast, smooth user experience has a significant impact on visitor satisfaction, conversion rate, and search engine ranking. One of the most effective techniques for improving load times on a Virtual Private Server (VPS) is caching. In this article, we explore what caching is, how it works, and the benefits it brings to your VPS-hosted website. ## What is caching? Caching is the process of temporarily storing frequently used data — or entire web pages — so they can be served quickly to subsequent visitors. Instead of dynamically generating a web page on each request, the web server can serve a cached version. That reduces server load and speeds up page loads for site visitors. ## How does caching work? Caching works by keeping a static copy of elements of your website — images, CSS and JavaScript files, and HTML pages. When a visitor reaches your site, the server first checks whether it has a cached version of the requested page. If it does, the server returns the cached page. If the page is not in the cache or the cache has expired, the server generates the page dynamically, caches it for later use, and then returns it to the visitor. ## A powerful strategy ## The benefits of caching on a VPS Now that we understand the basics of how caching works, let's look at the specific benefits it brings to a VPS-hosted website: ### 1. **Significantly faster page loads** One of the most obvious benefits of caching is faster page loads. Your visitors get quicker access to your content, which can lower your bounce rate and increase time on site. ### 2. **Lower server load** By storing cached versions of your pages, the load on your server drops because it does not need to regenerate the same page from scratch on every visit. That means your VPS can handle more visitors without sacrificing performance. ### 3. **Bandwidth savings** Caching reduces the amount of data transferred between server and visitor browser. That can translate to bandwidth savings — particularly useful if you are on a tight budget or pay for overage. ### 4. **Better search engine ranking** Search engines such as Google factor page-load speed into their ranking algorithms. By improving your site's speed through caching, you can potentially improve your search ranking. ## Conclusion Caching is a powerful strategy for speeding up your VPS-hosted website. It improves user experience, lowers server load, saves bandwidth, and can even help your search ranking. If you are looking to optimise your website's performance, seriously consider caching as one of your main optimisation strategies. It can make a significant difference for your visitors and your online business. # Who Will Succeed CentOS? Source: https://blog.onetsolutions.net/en/centos-successor-almalinux With Red Hat moving CentOS to CentOS Stream, AlmaLinux has emerged as a serious alternative — now available on our VPS as a one-click install. Who Will Succeed CentOS? *Published on October 3, 2021* After Red Hat's decision to change direction for CentOS — moving it to CentOS Stream as of January 1, 2022 — we understand the need for a serious alternative to this distribution. ### AlmaLinux: a serious alternative to CentOS AlmaLinux is a fork developed by CloudLinux. > "In an effort to fill the gap soon to be left by the disappearance of CentOS as a stable release, AlmaLinux was developed in close collaboration with the Linux community" said Aboutaboul in a statement. "These efforts resulted in a production-ready alternative to CentOS, backed by community members" — AlmaLinux Community Manager. CloudLinux was founded in 2009 to deliver a customised, performant and secure CentOS fork for web hosting providers. We use it ourselves to harden our cPanel and Plesk servers. The stable version of AlmaLinux is now available as a one-click install on our VPS. # Copy Fail (CVE-2026-31431): Linux Kernel Local Privilege Escalation Source: https://blog.onetsolutions.net/en/copy-fail-cve-2026-31431 A critical Linux kernel cryptographic-subsystem flaw lets a local user become root. Analysis, scope, and mitigation. *Published on May 1, 2026* **CVE-2026-31431 — nicknamed "Copy Fail".** A local privilege escalation bug present in nearly every recent Linux kernel. If your server runs third-party code or grants shell access, treat the mitigation as a priority. ## The bug in two sentences The flaw lives in the Linux kernel's cryptographic subsystem, exposed through the **AF\_ALG** interface (`algif_aead` module). It lets locally-running code with limited rights write into kernel memory and walk back out with `root` privileges. In practice, two exploitation paths stand out: * **User account → root** on a regular server. * **Container escape** to the host node on Docker or Kubernetes — pod isolation collapses entirely. An attacker needs a local foothold first (a user account, a pod, code embedded in a dependency, etc.). Without one, the flaw is not remotely exploitable. ## Sizing your exposure Rather than a binary "critical / not critical", the right question is: **who can execute code on your systems?** | Profile | Exposure | Action | | - | - | - | | Single-tenant VPS, your code only, no third parties | Low | Wait for the kernel patch and schedule the upgrade | | VPS hosting multiple customers, multiple shell accounts, or running unaudited code (shared CI, plugins, user runtimes) | **Critical** | Mitigate immediately, then patch | | Kubernetes cluster orchestrating third-party pods or dynamic workloads | **Critical** | Roll out a mitigation DaemonSet across every node | ## Immediate mitigation The real fix will be a kernel update. Until your distribution ships it, the workaround is to disable the offending module. The change is reversible and has no impact on the large majority of application workloads. ### Debian, Ubuntu and derivatives ```bash theme={null} # Block the module from being reloaded on next boot echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf # Unload the copy currently resident in memory sudo rmmod algif_aead 2>/dev/null || true ``` ### RHEL, AlmaLinux, Rocky Linux, CentOS and Fedora A slightly different path: the module is neutralised through GRUB at kernel init time. ```bash theme={null} sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init sudo reboot ``` ### Kubernetes clusters If you run Kubernetes on top of your VPS, propagate the mitigation across every node with a privileged DaemonSet. The trailing `pause` container keeps the DaemonSet alive after the `initContainer` finishes, so the system does not loop trying to restart it. ```yaml theme={null} apiVersion: apps/v1 kind: DaemonSet metadata: name: disable-algif-aead namespace: kube-system spec: selector: matchLabels: app: disable-algif-aead template: metadata: labels: app: disable-algif-aead spec: hostPID: true tolerations: - operator: Exists effect: NoSchedule - operator: Exists effect: NoExecute initContainers: - name: disable-algif-aead image: alpine:3.23 securityContext: privileged: true command: - /bin/sh - -c - | echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null || true volumeMounts: - name: modprobe-d mountPath: /etc/modprobe.d containers: - name: pause image: registry.k8s.io/pause:3.10 resources: limits: cpu: 1m memory: 8Mi volumes: - name: modprobe-d hostPath: path: /etc/modprobe.d ``` ## Verifying the mitigation is in effect A quick check after applying: ```bash theme={null} # The module should no longer be listed lsmod | grep algif_aead # And any load attempt must fail sudo modprobe algif_aead 2>&1 # expected: "install /bin/false algif_aead" followed by a failure ``` If `lsmod` returns nothing and `modprobe` fails, you are good. ## Reverting If a specific service relies on the kernel's `AF_ALG` API (uncommon outside low-level cryptographic use cases), you can re-enable the module: ```bash theme={null} sudo rm /etc/modprobe.d/disable-algif.conf sudo modprobe algif_aead ``` On RHEL and derivatives, also drop the kernel parameter: ```bash theme={null} sudo grubby --update-kernel=ALL --remove-args=initcall_blacklist=algif_aead_init sudo reboot ``` ## What's next Track your distribution's advisories — the kernel patch is the real destination, the module knockout is only a stopgap. For technical questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # cPanel, Plesk, or Webmin: Which Should You Pick? Source: https://blog.onetsolutions.net/en/cpanel-vs-plesk-vs-webmin A side-by-side look at popular VPS control panels — cPanel, Plesk, Webmin, Virtualmin, and ISPConfig — to help you pick the right one. cPanel, Plesk, or Webmin: Which Should You Pick? *Published on February 4, 2024* When it comes to managing the hosting of your sites on your VPS, choosing the right control panel is critical. A good control panel makes daily management easier, offers a friendly interface, and gives you full control over your server's features. In this article we compare several popular control panels to help you make an informed decision. ## 1. **cPanel** **Pros:** * Intuitive and friendly interface. * Wide range of features, including domain, database, and email account management. * Supports many Linux distributions. **Cons:** * High cost, generally based on a per-server licence. * Works best on CentOS-based systems. ## 2. **Plesk** **Pros:** * Sleek, easy-to-use graphical interface. * Supports multiple Linux distributions and Windows. * Centralised management of multiple servers. **Cons:** * Paid licence, though cheaper than cPanel. * More complex configuration for beginners. ## 3. **Webmin** **Pros:** * Free and open-source. * Simple web interface for server configuration. * Supports a variety of Linux distributions. **Cons:** * Fewer advanced features compared to cPanel or Plesk. * May require basic command-line knowledge. ## 4. **Virtualmin** **Pros:** * Built on top of Webmin, so free and open-source. * Designed specifically for managing web servers. * Easy to install and configure. **Cons:** * Fewer advanced features than cPanel or Plesk. * The interface can feel less polished. ## 5. **ISPConfig** **Pros:** * Free and open-source. * Supports managing multiple servers. * Friendly interface. **Cons:** * Fewer advanced features than cPanel or Plesk. * Steeper learning curve for beginners. ## Conclusion Picking a control panel depends on your specific needs. If you are looking for an all-inclusive solution with professional support, cPanel or Plesk may be the best options. If you prefer an open-source approach, Webmin, Virtualmin, or ISPConfig may fit the bill. Be sure to weigh ease of use, cost, and features before deciding. In the end, each of these control panels has its own strengths and weaknesses. Test them, look closely at the features, and pick the one that fits your workflow and meets your specific requirements. Managing your VPS will be more efficient when you use a control panel that matches your needs. # CUPS: Remote Code Execution via cups-browsed (CVE-2024-47076 and friends) Source: https://blog.onetsolutions.net/en/cups-rce-2024 Four chained CUPS flaws let an attacker register a malicious printer and gain RCE when a user prints to it. *Published on September 27, 2024* **CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, CVE-2024-47177.** Four flaws in CUPS and `cups-browsed`. RCE is not instant — it requires a user to print to the booby-trapped printer — but the surface is wide: any Linux server with `cups-browsed` enabled and port `631/UDP` reachable is a candidate. ## Why the perimeter is narrower than the headlines suggested When this CVE bundle was disclosed, the headlines screamed "9.9 out of 10" and "critical Linux vulnerability". The reality is more nuanced: 1. The flaw is not exploitable without `cups-browsed` running. 2. `cups-browsed` is not installed by default on most production servers (it is a desktop-environment dependency, not a web-server one). 3. Even with `cups-browsed` running, **RCE only fires when a user prints to the malicious printer**. That said, the risk does exist on machines that match the profile — Linux workstations, some development environments, containers built on "desktop" images — and exploitation is trivial once those conditions are met. ## The attack chain CUPS listens on `631/UDP` when `cups-browsed` is active. The attacker sends an IPP (Internet Printing Protocol) packet announcing a remote printer. `cups-browsed` **automatically registers it** on the target server. From that point, the printer shows up in the system's printer list. When a user prints to that printer (by mistake, by confusing it with a legitimate one, or because its name imitates a real printer), CUPS builds a print command from the IPP attributes the attacker provided. Some of those attributes are not validated: they can contain shell commands that get executed with the rights of the CUPS daemon. ## Are you affected? Check two things on each host: ```bash theme={null} # 1. Is cups-browsed running? systemctl is-active cups-browsed # 2. What versions of CUPS / cups-filters are you running? cups-config --version cups-browsed --version ``` Vulnerable versions: * `cups-browsed` ≤ 2.0.1 * `cups-filters` ≤ 2.0.1 * `libcupsfilters` ≤ 2.1b1 * `libppd` ≤ 2.1b1 ## Mitigation ### Clean fix: disable cups-browsed if you do not need it On a server, this is almost always the right move: ```bash theme={null} sudo systemctl disable --now cups-browsed ``` ### Middle ground: restrict discovery If `cups-browsed` must stay active, disable automatic discovery of remote printers through `BrowseRemoteProtocols`. Edit `/etc/cups/cups-browsed.conf`: ```text theme={null} BrowseRemoteProtocols none ``` (Default value: `dnssd cups`.) Then: ```bash theme={null} sudo systemctl restart cups-browsed ``` ### Network layer Block `631/UDP` on the firewall from the internet and from any shared, untrusted network. ## Patching Track the patch status through your distribution: * Ubuntu: follow the Ubuntu Security tracker for `cups-filters`. * Debian: `apt list --upgradable | grep -i cups`. * RHEL/AlmaLinux: `dnf check-update cups\*`. ## Wrap-up On a typical production server (web, database, cache), you are probably unaffected. On a Linux workstation or a desktop-style container, check `cups-browsed`, disable it if you can, patch otherwise. For questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # Debian 10 Source: https://blog.onetsolutions.net/en/debian-10 Debian 10 Buster is now available for one-click install on our VPS, with AppArmor enabled by default for stronger access control. Debian 10 *Published on July 20, 2019* We have just released the latest version of Debian 10 Buster as a one-click install on our VPS. This is the most polished release Debian has ever shipped. To install it, just pick Debian 10 from your SoPanel. With Buster, Debian ships an access-control framework enabled by default for the very first time. AppArmor is enabled by default in Debian Buster. AppArmor is an access-control framework that restricts what programs can do (mount, ptrace and signal permissions, as well as read, write and execute rights) by defining per-program profiles. # Debian 11 Bullseye Source: https://blog.onetsolutions.net/en/debian-11-bullseye Debian 11 Bullseye is now available for one-click install on our VPS at no extra cost — with kernel 5.10 LTS, native WireGuard, and exFAT support. Debian 11 Bullseye *Published on October 2, 2021* The long-awaited new version of Debian has finally arrived and is now available as a one-click install on our VPS, at no extra cost. This release — Debian 11, codename Bullseye — brings a long list of new features and improvements. For starters, Debian 11 ships more than 11,294 new packages. That is a significant change, since 72% of the packages have been updated since the previous version, Debian 10. With this massive update you get the latest features and improvements available in the Debian ecosystem. One of the highlights of this release is the integration of the Linux 5.10 kernel as an LTS (Long Term Support) version, with five years of support. Debian 11 also natively supports WireGuard, a secure and fast VPN protocol. Debian 11 ships a wide variety of applications and desktop environments. You can pick from GNOME 3.38, KDE Plasma 5.20, LXDE 11, LXQt 0.16, MATE 1.24, and Xfce 4.16. That diversity lets you choose the desktop that best fits your needs and preferences. Bullseye is also the first Debian release to include native exFAT support — and exFAT is now used by default to mount exFAT filesystems. This makes it easier to use and exchange data on exFAT-compatible storage media. We are happy to make this new Debian release available on our VPS so you can take advantage of the latest technical advances and a robust, performant operating system. Feel free to upgrade your VPS to Debian 11 and enjoy all the improvements it brings. Try this new release on our [VPS](https://onetsolutions.net/serveur-vps)! # Debian 12 Bookworm Source: https://blog.onetsolutions.net/en/debian-12-bookworm Debian 12 is now available on our VPS — bringing the Linux 5.10 kernel, stronger security with AppArmor and seccomp, and an improved apt experience. Debian 12 Bookworm *Published on June 11, 2023* We are excited to let you know that Debian 12 is now available on our virtual private servers (VPS). This latest stable Linux release brings a long list of exciting technical advances. In this article we cover what is new in Debian 12 and why these improvements benefit our customers. ### Linux 5.10 kernel for optimised performance One of the most notable aspects of Debian 12 is the Linux 5.10 kernel. This new version brings a set of significant optimisations, security fixes, and power-management improvements. OnetSolutions VPS users will see better responsiveness, more efficient hardware resource usage, and increased performance for their applications and websites. ### Enhanced security with Debian 12 Security is a major concern at OnetSolutions, and Debian 12 addresses it with major updates to security packages and patches for known vulnerabilities. VPS users get stronger protection thanks to the latest security measures integrated into Debian 12. Advanced technologies such as AppArmor and seccomp further harden server security by limiting exploitation and unauthorised-access risks. ### Simpler VPS management with Debian 12 Managing your VPS is now simpler and more efficient thanks to the improvements in Debian 12. The `apt` package manager has been improved to offer optimised dependency handling and faster, more accurate conflict resolution. You will find software and update management simpler — leaving more time for development and improving your applications. ### Broader compatibility for today's needs Debian 12 is designed to be compatible with the latest hardware and software technologies. You can run web applications, databases, and other services without worrying about compatibility. This broad compatibility means OnetSolutions customers can take advantage of the latest technological advances and enjoy an optimal VPS experience. *** The optimised performance of the Linux 5.10 kernel, enhanced security, simpler management, and broader compatibility deliver many benefits to OnetSolutions VPS users. Debian 12 is a solid choice for users who want cutting-edge technical features and proven stability. With this new release, users can expect a smoother experience, improved performance, and stronger security. By choosing OnetSolutions as your Debian 12 VPS provider, you get the reliability and expertise of a company well-known in the hosting and IT-solutions space. The OnetSolutions team is ready to provide skilled technical support and guide you in making the most of Debian 12. Whether you are a developer, sysadmin or business looking for a robust hosting environment, OnetSolutions Debian 12 VPS are a smart choice. Enjoy the improved performance, enhanced security, and simpler management this new Linux release offers. # Debian 13 Trixie: New Features and Improvements Source: https://blog.onetsolutions.net/en/debian-13-trixie Debian 13 'Trixie' is now available as a one-click install on our VPS — with kernel 6.12 LTS, GNOME 48, KDE Plasma 6.3, and 14,100 new packages. Debian 13 Trixie: New Features and Improvements *Published on August 16, 2025* The Debian project has just announced the release of its new stable version: **Debian 13 "Trixie"**, after more than two years of development. This release marks an important milestone for the free-software community and brings a long list of new features, optimisations, and updates. At **OnetSolutions**, we are happy to announce that **Debian 13 is now available as a one-click install on all our VPS**. You can deploy your new servers and benefit immediately from the advances of this iconic distribution. *** ## What's new in Debian 13? Debian 13 "Trixie" comes with many improvements: * New desktop environments: **GNOME 48, KDE Plasma 6.3, Xfce 4.20, LXQt 2.1.0, LXDE 13** * More than **44,000 updated packages** and **14,100 new packages** * Linux **6.12 LTS** kernel — even faster and more secure * Official support for the **64-bit RISC-V** architecture * Major updates to popular software: Apache 2.4.64, MariaDB 11.8, PostgreSQL 17, PHP 8.4, Python 3.13, Rustc 1.85, LibreOffice 25.2, GIMP 3.0.4, and many more * Installer and hardware-support improvements * A stronger effort on reproducible builds and security With its 5-year support window, Debian 13 confirms its status as a **universal system**, suited to both desktop environments and critical servers. *** ## Debian 13 at OnetSolutions We know reliability and security are essential to your projects. That is why Debian remains one of the most popular operating systems on our VPS infrastructure. Starting today, you can: * Create an OnetSolutions VPS with **Debian 13 Trixie pre-installed** in a few clicks * Take advantage of an **automated install** optimised for the cloud * Quickly start your web projects, databases, or development environments on the latest Debian release *** ## Why pick Debian on a VPS? * **Proven stability**: fast security updates and long-term support * **Performance**: a recent Linux kernel optimised for modern workloads * **Versatility**: equally at home on web servers and critical applications * **Reliability**: used by thousands of companies, government agencies, and organisations worldwide *** ## Get started now Want to try Debian 13 or migrate your existing services?\ Log in to your OnetSolutions client area and deploy your VPS with **Debian 13 Trixie** in an instant. *** With **Debian 13 on our VPS**, get the best of open source — ready to use and effortless to install. # Your domain on your VPS, without writing a record Source: https://blog.onetsolutions.net/en/domain-linked-to-vps Point a domain at your instance from the console: the records are written for you, and you see what changes before it changes. *Published on September 24, 2026* Pointing a domain at a server has always meant the same thankless work: find the IP address, open the zone editor, create an A, an AAAA, a www, remember the CAA. Miss one and the site does not answer; overwrite one and the email stops. A **Domain** tab now appears on your instances. You pick a domain you own, you say what the server is for, and the records are written from the instance's own addresses. You never open the zone editor. ## You see it before it changes This is the part that matters most, and the part missing almost everywhere else. Before anything is written, the preview shows every record: the ones that will be created, the ones already correct, and the ones that will be **replaced — with the value they hold today beside the new one**. One case makes this worth having. If your email is hosted elsewhere — Google, Microsoft, anyone — pointing MX at your VPS stops your mail from arriving. Plenty of tools do it silently. Here your current MX records appear as a replacement, in plain sight, and you decide. ## Three profiles, depending on what the server does | Profile | Writes | Leaves alone | | - | - | - | | A website | A, AAAA, www, CAA | your email | | A website and email | the above, plus mail, MX, SPF, DMARC, and the reverse DNS | — | | Cloudron | my and the `*` wildcard, CAA | your email | The Cloudron profile only appears on an instance running Cloudron. It writes the two records that panel needs to give each application its own subdomain — without them, it does not work. ## The reverse DNS your registrar cannot set The email profile also sets the reverse DNS of the IP address. It is the only record on this list no registrar can create for you: the address is ours. Mail servers check it before accepting your messages, and its absence is a common reason for mail landing in spam. ## When the address changes A reinstall or a migration can change the instance's primary address. Attached domains follow: their A and AAAA records are rewritten to the new address, with nothing to do. ## Getting started The **Domain** tab is available on your instances from the [console](https://console.onetsolutions.net/compute/instances). It offers the domains in your organization whose DNS zone we host. The documentation covers each profile and what it writes: [Point a domain to a VPS](https://help.onetsolutions.net/vps/redirect-my-domain). # ebtables SNAT (CVE-2026-53266): an Out-of-Bounds Kernel Write, Exploited in the Wild Source: https://blog.onetsolutions.net/en/ebtables-snat-cve-2026-53266 A flaw in the ebtables bridge firewall lets an attacker write into the kernel page cache. In CISA's KEV catalog since September 18. Scope and mitigation. *Published on September 24, 2026* **CVE-2026-53266, in the ebtables SNAT target.** Added to CISA's KEV catalog on September 18, 2026: it is being exploited in the wild. Fixes have shipped for Debian, RHEL 8 and 9, AlmaLinux and Ubuntu 26.04 — but not yet for Ubuntu 22.04 or 24.04. On those two releases, apply the mitigation now. ## The problem in two sentences The `snat` target of ebtables, the Linux bridge firewall, can rewrite the sender hardware address in ARP packets. The `ebt_snat` module performs that write through `skb_store_bits()` without first making sure the target memory range is writable. When that range is a file page imported with `splice()`, the kernel writes straight into the page cache. NVD classifies the flaw as an out-of-bounds write (CWE-787), with a CVSS score of 8.8. ## Why this one matters On paper, the flaw needs an unusual setup: an ebtables SNAT rule with ARP rewriting (`--snat-arp`) on a bridge. Red Hat describes it as requiring "specific bridge netfilter configurations". That is true, but incomplete. **The attacker can build that setup themselves.** All it takes is `CAP_NET_ADMIN` in the network namespace that owns the bridge. Where unprivileged user namespaces are allowed, any ordinary account gets it with `unshare -Urn`, inside its own namespace, without touching the host configuration. **The module loads itself.** `ebt_snat` is loaded automatically as soon as a rule needs it. Its absence from `lsmod` today protects you from nothing. **The write lands in the page cache.** Six controlled bytes written into a file page are enough to modify, in memory, a file the attacker can read but not write — a setuid binary, for instance. These three points come from the [public tracker for the flaw](https://github.com/suominen/CVE-2026-53266), not from the distribution advisories, which do not describe the attack path. CISA does not say how the exploitation it observed was carried out either. ## Sizing your exposure There are two questions: **who can run code on the machine, and can they obtain `CAP_NET_ADMIN`?** | Profile | Exposure | Action | | - | - | - | | Single-tenant VPS, your code only, no third-party shell accounts | Moderate | Patch and reboot. On Ubuntu 22.04 or 24.04, mitigate in the meantime | | VPS with several shell accounts, customers, or an unaudited CI runner | **Critical** | Mitigate now, patch as soon as the kernel is available | | Docker or Kubernetes node where containers run with `NET_ADMIN` or in privileged mode | **Critical** | Mitigate on every node, drop `NET_ADMIN` wherever it is not strictly required | | Virtualisation host using ebtables SNAT rules with `--snat-arp` on its bridges | **Critical** | Patch the kernel. Do not block the module before checking what it breaks | | Shared hosting where you do not manage the kernel | Handled by the provider | Nothing to do on your side | As usual with this class of bug, a local foothold is required. The flaw is not remotely exploitable on its own, but it turns a compromised web application or a low-privilege account into control of the machine. To check whether an unprivileged account can create its own network namespace: ```bash theme={null} # Run as a regular user, not root unshare -Urn true && echo "user namespaces available" # On Debian and Ubuntu kernels: 1 = allowed, 0 = forbidden sysctl kernel.unprivileged_userns_clone ``` ## Applying the fix The upstream fix landed in Linux 7.1-rc7. It makes the ARP address range writable before reading and rewriting it. ### Debian, Ubuntu and derivatives ```bash theme={null} # Upgrade the kernel sudo apt update sudo apt full-upgrade # The new kernel only runs after a reboot sudo reboot ``` Status as of September 24, 2026, per the [Debian](https://security-tracker.debian.org/tracker/CVE-2026-53266) and [Ubuntu](https://ubuntu.com/security/CVE-2026-53266) trackers: | Release | Fixed kernel package | | - | - | | Debian 11 (bullseye, LTS) | `linux 5.10.259-1` (DLA-4664-1), `linux-6.1 6.1.176-1~deb11u1` (DLA-4671-1) | | Debian 12 (bookworm) | `linux 6.1.176-1` | | Debian 13 (trixie) | `linux 6.12.94-1` | | Ubuntu 26.04 LTS | `linux 7.0.0-31.31` | | Ubuntu 24.04 LTS | **No fix yet** — mitigation required | | Ubuntu 22.04 LTS | **No fix yet** — mitigation required | | Ubuntu 20.04 LTS | Vulnerable, no fix announced | | Ubuntu 18.04 LTS | Not affected | ### AlmaLinux, Rocky Linux and RHEL ```bash theme={null} sudo dnf clean metadata && sudo dnf upgrade sudo reboot ``` | Release | Fixed kernel | Advisory | | - | - | - | | RHEL / AlmaLinux 8 | `kernel-4.18.0-553.143.1.el8_10` | RHSA-2026:39083, ALSA-2026:39083 | | RHEL / AlmaLinux 9 | `kernel-5.14.0-687.23.1.el9_8` | RHSA-2026:36645, ALSA-2026:36645 | | AlmaLinux 10 | `kernel-6.12.0-211.59.1.el10_2` | ALSA-2026:71233, released September 24 | Red Hat also ships `kernel-rt-4.18.0-553.143.1.rt7.484.el8_10` for the RHEL 8 real-time kernel (RHSA-2026:39082). Any later version than those listed includes the fix. ## Immediate mitigation Apply this if your fixed kernel is not out yet, or until you are able to reboot. ### Block the `ebt_snat` module Without the module, the ebtables SNAT target no longer exists — and neither does the vulnerable path. ```bash theme={null} # Prevent any further loading of the module printf 'install ebt_snat /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-53266.conf # Unload it if it is already in memory sudo modprobe -r ebt_snat ``` If you run a host that relies on ebtables SNAT rules, this block breaks them. Red Hat offers another route for that case: remove the ARP rewrite option from those rules, or delete the SNAT rules that apply to ARP traffic. List them with `sudo ebtables -t nat -L`. ### Disable unprivileged user namespaces (Debian and Ubuntu) A second barrier: stop an ordinary account from obtaining `CAP_NET_ADMIN` in a namespace of its own. This setting exists on Debian and Ubuntu kernels. ```bash theme={null} # Takes effect immediately sudo sysctl -w kernel.unprivileged_userns_clone=0 # Persist across reboots echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cve-2026-53266.conf ``` This breaks anything that depends on those namespaces, rootless containers in particular. Check what you run before applying it in production. ### On a Kubernetes cluster Roll the module block out to every node with a privileged DaemonSet. The `pause` container keeps the DaemonSet from restart-looping once the `initContainer` finishes. ```yaml theme={null} apiVersion: apps/v1 kind: DaemonSet metadata: name: disable-ebt-snat namespace: kube-system spec: selector: matchLabels: app: disable-ebt-snat template: metadata: labels: app: disable-ebt-snat spec: hostPID: true tolerations: - operator: Exists effect: NoSchedule - operator: Exists effect: NoExecute initContainers: - name: disable-ebt-snat image: alpine:3.23 securityContext: privileged: true command: - /bin/sh - -c - | printf 'install ebt_snat /bin/false\n' > /etc/modprobe.d/cve-2026-53266.conf rmmod ebt_snat 2>/dev/null || true volumeMounts: - name: modprobe-d mountPath: /etc/modprobe.d containers: - name: pause image: registry.k8s.io/pause:3.10 resources: limits: cpu: 1m memory: 8Mi volumes: - name: modprobe-d hostPath: path: /etc/modprobe.d ``` ## Verifying the mitigation ```bash theme={null} # The module must not be listed lsmod | grep ebt_snat # Any attempt to load it must fail sudo modprobe ebt_snat # On Debian and Ubuntu, if you disabled user namespaces: must print 0 sysctl kernel.unprivileged_userns_clone ``` After the kernel upgrade, confirm it is the one actually running: ```bash theme={null} # Must show the fixed version uname -r ``` A package installed without a reboot protects nothing: the machine is still running the old kernel. ## Rolling back the mitigation Once the fixed kernel is booted, you can revert: ```bash theme={null} sudo rm /etc/modprobe.d/cve-2026-53266.conf sudo rm /etc/sysctl.d/99-cve-2026-53266.conf sudo sysctl -w kernel.unprivileged_userns_clone=1 ``` ## What next? The flaw was disclosed on June 25 and fixed by Red Hat as early as July 8, but only entered the KEV catalog on September 18. Put differently, fixes had been available for more than two months when exploitation was confirmed. If your servers have not rebooted onto an updated kernel since July, treat the window as open. If you have doubts about a machine, do not clean it in place: rebuild it from a known-good state using your [snapshots](https://help.onetsolutions.net/vps/snapshot) and [backups](https://help.onetsolutions.net/vps/backup), then rotate every secret it held. Want a second opinion on your fleet? [Our team is available](https://help.onetsolutions.net/console/support) from your customer area. # Hardening a Linux VPS: Tips and Tools Source: https://blog.onetsolutions.net/en/enhanced-vps-linux-security Practical tips and recommended tools — iptables, SSH keys, Fail2ban, OpenVAS, Logwatch, ModSecurity — to harden your Linux VPS. Hardening a Linux VPS: Tips and Tools *Published on October 7, 2023* When you run a Linux Virtual Private Server (VPS) to host your website or applications, the security of your sensitive data becomes a major concern. A Linux VPS gives you valuable control and flexibility, but that also means you are responsible for the security of your server. In this article, we cover essential tips for hardening your Linux VPS and protecting your sensitive data from online threats. We also recommend security tools to help with this critical task. ## 1. Keep your operating system up to date One of the first steps to harden your Linux VPS is keeping the operating system up to date. Linux distributions release security updates frequently. Applying them closes known vulnerabilities that attackers could exploit. Use tools such as `yum` or `apt` to manage your system updates. ## 2. Use a firewall (iptables) Set up a firewall such as iptables on your Linux VPS to control incoming and outgoing traffic. Allow only the ports your application needs and block everything else. Iptables is a powerful tool for defining custom firewall rules. ## 3. Use encrypted connections (SSH) When connecting to your Linux VPS remotely, use SSH (Secure Shell) for a secure connection. Disable root login over SSH and configure key-based authentication for stronger security. You can use tools such as `ssh-keygen` to generate SSH key pairs. ## 4. Network security with Fail2ban Install and configure Fail2ban to detect and block failed authentication attempts on your Linux VPS. Fail2ban watches system logs to identify malicious IP addresses and temporarily blocks them. ## 5. Use a vulnerability scanner (OpenVAS) OpenVAS is an open-source vulnerability scanner that helps you identify weaknesses in your Linux VPS. It runs deep scans and provides detailed reports so you can take corrective action. ## 6. Monitor activity logs (Logwatch) Logwatch summarises system activity logs and emails you regular reports. It lets you keep an eye on suspicious activity on your Linux VPS and react quickly when something is off. ## 7. Use a Web Application Firewall (WAF) (ModSecurity) Install ModSecurity, an open-source Web Application Firewall (WAF), to protect your web application against common attacks such as SQL injection and cross-site scripting (XSS). ## Conclusion Linux VPS security is essential to protecting your sensitive data and keeping your online activities running. By following these tips and using the recommended tools, you can harden your Linux VPS and minimise the risk of online attacks. Stay vigilant, monitor your server regularly, and keep up with the latest threats to maintain optimal security on your Linux VPS. # Get a Domain Name for Free Source: https://blog.onetsolutions.net/en/free-domain-name A well-chosen domain name strengthens your online presence and SEO. ONETSOLUTIONS includes a free domain name with every web hosting plan. Get a Domain Name for Free *Published on August 1, 2019* Your domain name is a key part of your website. It plays a crucial role in your online visibility and helps your SEO, in line with your business goals. A well-chosen domain name can strengthen your online presence and attract more visitors. It is essential to pick something relevant to your activity, easy to remember, and tied to your brand. A clear and memorable domain name helps users recognise your site, which encourages engagement and interaction with your content. A well-optimised domain name can also have a positive impact on SEO. When your domain is tied to your relevant keywords, search engines can better understand the content of your site and match it to relevant queries. That improves your ranking in search results and your visibility with your target audience. In short, a carefully chosen domain name is a major asset for your website. It improves your online visibility, strengthens your brand, and supports your SEO. Pay close attention to the domain name you choose — it is part of your success on the web. At ONETSOLUTIONS, we include the domain name for free in [our plans](https://onetsolutions.net/web-hebergement). That means you can get your `brand.fr` / `.com` / `.net` / etc. for free, the moment your hosting is activated. You can then set up your site, store or forum and make it discoverable by search engines. Get in touch if you would like more information! A few links: * [Web hosting](https://onetsolutions.net/web-hebergement) * [Domain names](https://onetsolutions.net/web-nomdedomaine) * [Install WordPress, PrestaShop, Drupal in two clicks](https://onetsolutions.blog/hebergement-web-installer-en-deux-clics-wordpress-prestashop-drupal/) * [Matomo analytics](https://onetsolutions.blog/hebergement-web-statistiques-matomo/) # How to Get a Free SSL Certificate Source: https://blog.onetsolutions.net/en/free-ssl-certificate-for-web-hosting Our entire shared hosting infrastructure now serves HTTPS, with a free SSL certificate compatible with most browsers. How to Get a Free SSL Certificate *Published on August 1, 2019* Our entire [shared hosting](https://onetsolutions.net/web-hebergement) infrastructure is now reachable over HTTPS. Your sites can use a free SSL certificate compatible with most browsers. **What is an SSL certificate?** An SSL certificate secures the traffic between your visitors and your website. With SSL, communications are encrypted. **Why does it matter?** Securing traffic is a priority — especially for an online store. The certificate also helps with search engine ranking, on Google for instance: * Better visibility on Google * A trust signal for your visitors **How do I get it?** You first need a [shared hosting](https://onetsolutions.net/web-hebergement) plan with ONETSOLUTIONS. After that, activation is automatic (within 24 hours of your hosting being activated) and requires no action on your part. The certificate covers your domain — both `yourdomain.com` and `www.yourdomain.com`. To check the certificate, you can use this site: [https://www.ssllabs.com/ssltest/analyze.html](https://www.ssllabs.com/ssltest/analyze.html) If you have any questions, open a ticket from your ONETSOLUTIONS client area. # GhostLock (CVE-2026-43499): Fifteen Years of Kernel, Root in Five Seconds Source: https://blog.onetsolutions.net/en/ghostlock-cve-2026-43499 A use-after-free in the kernel futex priority-inheritance path turns any local user into root and escapes containers. No workaround — only a reboot. *Published on August 8, 2026* **CVE-2026-43499 — nicknamed "GhostLock".** A public exploit reaches root from an unprivileged account in about five seconds. There is no runtime mitigation: the only fix is a patched kernel followed by a reboot. ## The bug in two sentences The flaw is a use-after-free in the kernel locking subsystem, on the futex priority-inheritance path — the machinery behind glibc's `PTHREAD_PRIO_INHERIT` mutexes. A cleanup step in `remove_waiter()` clears the wrong thread's bookkeeping, leaving a live thread pointing at memory that has already been freed. The freed object sits on the kernel stack rather than the heap, which is where most bugs of this class live. That detail is what makes the exploit so reliable. The only prerequisite is `CONFIG_FUTEX_PI=y`, enabled by default in every major distribution. The code was introduced in Linux 2.6.39-rc1 in May 2011 and remained vulnerable through v7.1-rc1 — so effectively every production kernel of the last fifteen years qualifies. ## Why this one is different Local privilege escalations are common and usually rank low on the priority list. Two properties push this one up. **The exploit is public and it works.** The published full chain reaches root in roughly five seconds at about 97% reliability. That is not a proof of concept requiring a specific kernel build and a favourable wind — it is a working tool. **It escapes containers.** An unprivileged process inside a container reaches root on the host. If you run untrusted or third-party workloads in containers on a shared node, the isolation you are relying on is not there. ## Sizing your exposure The question is not the CVSS score — it is 7.8, and that number tells you little here. The question is: **who can execute code on your machine?** | Profile | Exposure | Action | | - | - | - | | Single-tenant VPS, your code only, no shell accounts for third parties | Moderate | Patch during your next maintenance window | | VPS with several shell accounts, customers, or an unaudited CI runner | **Critical** | Patch and reboot now | | Docker or Kubernetes node running third-party images or dynamic workloads | **Critical** | Patch every node — container isolation does not hold | | Shared hosting where you do not manage the kernel | Handled by the provider | Nothing to do on your side | Note the pattern: the flaw needs a local foothold. It is not remotely exploitable on its own. But it turns any modest foothold — a compromised web application, a leaked low-privilege account, a hostile dependency in a build — into full control of the machine. ## There is no workaround This is the part that trips people up. Red Hat's bulletin states it plainly: no runtime kernel parameter and no module can be disabled to address the flaw. `CONFIG_FUTEX_PI` is compiled into standard builds and cannot be toggled while running. Unlike a flaw confined to a loadable module, you cannot buy yourself a week with a `modprobe` blacklist. Patch and reboot, or stay vulnerable. ## Patching ### Debian, Ubuntu and derivatives ```bash theme={null} # Pull the security updates and upgrade the kernel sudo apt update sudo apt full-upgrade # The new kernel is only active after a reboot sudo reboot ``` Check your distribution's tracker for the exact fixed package version: [Ubuntu](https://ubuntu.com/security/CVE-2026-43499) and [Debian](https://security-tracker.debian.org/tracker/CVE-2026-43499). ### AlmaLinux, Rocky Linux and RHEL ```bash theme={null} sudo dnf clean metadata && sudo dnf upgrade sudo reboot ``` Fixed kernel versions on AlmaLinux, or any later release: | Release | Fixed kernel | | - | - | | AlmaLinux 8 | `kernel-4.18.0-553.141.2.el8_10` | | AlmaLinux 9 | `kernel-5.14.0-687.24.1.el9_8` | | AlmaLinux 10 | `kernel-6.12.0-211.32.1.el10_2` | Red Hat's bulletin covers RHEL 6 through 10, along with OpenShift, OpenStack Platform, RHEL CoreOS, and every product built on the RHEL kernel. ### Verify the running kernel Installing the package is not the same as running it. Confirm after the reboot: ```bash theme={null} # Must show the patched version, not the one you booted this morning uname -r # How long the machine has been up — a large value after "patching" is the tell uptime -p ``` On a Kubernetes cluster, a node is only fixed once it has rebooted. Drain, reboot, uncordon, one node at a time — a patched package on a node that has not rebooted still runs the vulnerable kernel. ## Timeline The handling was orderly, which is worth noting: the flaw was reported on 18 April by Nebula Security, fixed upstream two days later in commit `3bfdc63936dd`, backported on 4 May, and only disclosed publicly on 7 July. Distributions had their patches ready before the details were out. The exploit followed within a day of disclosure. If your servers have not rebooted since early July, assume the window has been open the whole time. ## If you suspect a compromise A successful local escalation leaves few marks, and a root-level attacker can erase what does exist. Do not try to clean the machine in place. The reliable route is to rebuild from a known-good state: deploy a fresh instance, restore your data from a backup predating the suspicion, rotate every credential the machine held — SSH keys, API tokens, database passwords. Your [snapshots](https://help.onetsolutions.net/vps/snapshot) and [backups](https://help.onetsolutions.net/vps/backup) exist for exactly this. Reboots after a kernel update are the single most-skipped step in server maintenance. If you manage more than a handful of machines, an inventory of `uname -r` values is worth more than any scanner. Need a hand sizing up your fleet? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # How cPanel Simplifies Hosting Management Source: https://blog.onetsolutions.net/en/how-cpanel-makes-life-easier A look at cPanel — included for free in our web hosting plans starting at €1.90 — and everything you can manage with it in just a few clicks. How cPanel Simplifies Hosting Management *Published on July 20, 2019* Today we are giving you a tour of the tool we include for free in our web hosting plans, starting at €1.90. cPanel is an all-in-one tool that lets you manage every aspect of your account in just a few clicks: * Email * Databases * File manager * Backup & restore * PHP, error logs, statistics, sub-users, and more With cPanel, you can manage your web hosting easily — no technical knowledge required. Be sure to also check out another tool available inside cPanel: Installatron! Get in touch if you would like to know more! # Ingress Nightmare: Unauthenticated RCE on Kubernetes Clusters (Ingress NGINX) Source: https://blog.onetsolutions.net/en/ingress-nightmare-kubernetes-2025 Four chained CVEs in the Ingress NGINX controller let an unauthenticated attacker run code and ultimately take over the cluster. *Published on March 26, 2025* **Ingress Nightmare — CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974.** On a Kubernetes cluster using Ingress NGINX, an attacker who can reach the admission webhook can execute arbitrary code and, by cascade, take over the cluster. ## Scope The flaw affects **Ingress NGINX Controller** (not to be confused with NGINX Ingress Controller, the F5/NGINX-maintained project, which is a different product). Vulnerable versions: * all versions `< v1.11.0` * `v1.11.0` to `v1.11.4` * `v1.12.0` Quick check: ```bash theme={null} kubectl get pods --all-namespaces \ --selector app.kubernetes.io/name=ingress-nginx \ -o jsonpath='{.items[*].spec.containers[*].image}' ``` ## How the attack works When you install Ingress NGINX, an **admission controller** is deployed inside the cluster. Its job: validate `Ingress` objects before they are applied to NGINX. The problem: this webhook is reachable **on the cluster network, without authentication**, by default. An attacker who can reach the webhook (from a compromised pod, a poorly-isolated internal service, or sometimes directly from outside if the `Service` is exposed) sends a malicious `Ingress` object. The webhook processes the object, builds an NGINX configuration from it, and validates it by running the NGINX binary… which at that point interprets the injected payload. **RCE in the controller pod.** Then comes the cascade. The controller pod typically has rights to read `Secrets` across all namespaces (because it mounts TLS certificates). Once RCE is achieved, the attacker reads every secret in the cluster — internal credentials, cloud tokens, API keys. **Cluster takeover.** ## Patching Upgrade Ingress NGINX Controller to the latest stable version available — past anything listed as vulnerable. Follow your usual Helm/manifest procedure depending on your install. ## If you cannot patch right away Two surface-reduction measures to apply in the meantime: ### 1. Restrict network access to the webhook A `NetworkPolicy` that only lets the Kubernetes API server talk to the admission webhook: ```yaml theme={null} apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: ingress-nginx-admission-only-apiserver namespace: ingress-nginx spec: podSelector: matchLabels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/component: admission-webhook policyTypes: - Ingress ingress: - from: - ipBlock: cidr: ports: - port: 8443 protocol: TCP ``` Tune the CIDR to your cluster. ### 2. Temporarily disable the admission webhook If the `NetworkPolicy` is not workable and you intend to patch right after, you can disable the admission component. With Helm: ```bash theme={null} helm upgrade ingress-nginx ingress-nginx/ingress-nginx \ --reuse-values \ --set controller.admissionWebhooks.enabled=false ``` You lose admission-time validation of `Ingress` objects — so preventive safety on malformed configs — but you close the attack path until the patch is in. ## Wrap-up This is an RCE → secret theft → takeover chain that requires no authentication, on a component many clusters expose by default. A PoC is public. Patch, and use the moment to double-check the `NetworkPolicy` around every one of your admission webhooks. For questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # Windows Licensing Now Available Source: https://blog.onetsolutions.net/en/licensed-windows-vps-now-available Windows licences are now available on our VPS — unlimited users, no commitment, and €1.80 excl. VAT per month per vCPU. Windows Licensing Now Available *Published on November 14, 2021* You have been asking for it, and it is now available on our website: Windows licences! ## Unlimited users There is no user limit. You are the administrator of the service — we have no access to it. ## Unbeatable pricing Thanks to our partnership with Microsoft, we can offer a Windows licence as an optional add-on to your service for €1.80 excl. VAT per month per vCPU, with no commitment. ## No commitment You can switch to Linux and cancel the Windows licence at any time. The VPS itself is also commitment-free. ## Latest versions available We offer the two most recent versions of Windows Server Standard — 2019 and 2022 — as one-click installs. Support for 2019 ends in late 2024, and 2022 in late 2026. # LiteSpeed cPanel Plugin (CVE-2026-54420): From an FTP Account to Root on a Shared Server Source: https://blog.onetsolutions.net/en/litespeed-cpanel-cve-2026-54420 A symlink flaw lets any account with FTP or shell access reach root on shared hosting. In CISA's KEV catalog since June — check your plugin version. *Published on August 12, 2026* **CVE-2026-54420, CVSS 8.5.** Affects the LiteSpeed cPanel plugin **before 2.4.8**, shipped in the LiteSpeed WHM plugin **before 5.3.2.0**. Fixed in WHM plugin **5.3.2.1** or later. Added to CISA's Known Exploited Vulnerabilities catalog on 15 June 2026. ## Why this one is different Most advisories we publish concern software you run yourself. This one concerns the machine underneath a shared hosting account — and it inverts the trust model that shared hosting is sold on. The premise of shared hosting is that accounts are neighbours who cannot reach each other. CloudLinux and CageFS exist to enforce exactly that. This flaw lets one neighbour with nothing more than an FTP account walk out of their box and become root on the host. At that point every site on the server is readable, writable, and modifiable by someone who paid for the cheapest plan on it. ## The flaw The plugin mishandles symbolic links. An account with FTP or web shell access can plant a symlink that the plugin follows while running with elevated rights, and use that to escalate to root. No exploit of a memory bug, no race against a kernel. Just a privileged process trusting a path that an unprivileged user controls — the oldest shape of local privilege escalation there is, and still one of the most effective. Two properties make it serious rather than merely interesting: **The entry bar is low.** FTP access is the least-privileged thing a shared host hands out. It is what every customer gets, including the one who bought a plan with a stolen card an hour ago. **It is confirmed exploited.** CISA does not add flaws to KEV on theory. The catalog entry, dated 15 June 2026, means it has been used against real systems. The issue was reported by Namecheap on 31 May 2026 — a hosting provider finding it in its own fleet, which tells you something about where it shows up. ## Sizing your exposure | Profile | Exposure | Action | | - | - | - | | You are a customer on someone's shared hosting | Handled by the provider | Nothing to do — but it is fair to ask them | | You run WHM/cPanel with the LiteSpeed plugin below 5.3.2.1 | **Critical** | Update today, then look for signs of use | | You run WHM/cPanel with CloudLinux or CageFS | **Critical** | This is the exact configuration described | | You run LiteSpeed on a VPS without cPanel | None | The flaw is in the cPanel plugin, not the web server | | You run a single-tenant VPS, no untrusted accounts | Low | No hostile neighbour to exploit it — patch at the next window | Worth separating two things that share a name. This is a flaw in the **cPanel plugin** distributed by LiteSpeed, not in **LiteSpeed Web Server** itself. If you run LSWS on a VPS you manage alone, without cPanel, you are not in scope. ## Checking and updating Check the installed plugin version from WHM, or on the command line: ```bash theme={null} # Version of the LiteSpeed WHM plugin cat /usr/local/cpanel/whostmgr/docroot/cgi/lsws/VERSION 2>/dev/null # The cPanel-side plugin, which is the component the CVE names cat /usr/local/cpanel/base/frontend/*/lsws/VERSION 2>/dev/null ``` Update through WHM, or from the shell: ```bash theme={null} # Fetch and run the plugin installer cd /usr/src wget https://www.litespeedtech.com/packages/cpanel/lsws_whm_plugin_install.sh sh lsws_whm_plugin_install.sh ``` Then confirm you are on 5.3.2.1 or later before considering it closed. ## Looking for signs it was used Patching stops it happening again; it says nothing about the past. Because exploitation is confirmed in the wild, a server that ran a vulnerable version deserves a look. The tell is a burst of plugin calls in quick succession — the exploit needs several concurrent attempts to win. In the plugin's logs, look for `generateEcCert` immediately followed by `packageUserSize`, and for clusters of roughly seven to ten concurrent calls per attempt: ```bash theme={null} # Adjust the path to your LiteSpeed plugin log directory grep -rn "generateEcCert" /usr/local/lsws/logs/ | head -50 ``` Alongside that, the usual root-compromise checks: accounts added recently, SSH keys you did not install, and scheduled jobs nobody remembers writing. ```bash theme={null} # Accounts with a UID of 0 — there should be exactly one awk -F: '$3 == 0 {print $1}' /etc/passwd # Root's authorized keys cat /root/.ssh/authorized_keys 2>/dev/null # Root cron jobs crontab -l -u root 2>/dev/null ``` If any of that turns up something you cannot account for, treat the host as compromised. On a shared server that means every account on it, not just the one that was used as the way in — rebuild, restore customer data from backups predating the first suspicious event, and rotate every credential the machine held. ## What it says about shared hosting Nothing here argues against shared hosting. It argues for being clear about what it is: a machine where the isolation between accounts is a software product, and software products have bugs. If your workload genuinely cannot tolerate a hostile neighbour, the answer is not a better plugin — it is not sharing the kernel. That is the actual line between shared hosting and [a VPS](https://help.onetsolutions.net/vps/offers), and it is worth choosing deliberately rather than on price. Questions about your hosting with us? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # Web Analytics with Matomo Source: https://blog.onetsolutions.net/en/matomo-statistics-for-web-hosting Track visitor activity on your blog, store, forum or website with Matomo — included with our web hosting plans. Web Analytics with Matomo *Published on July 20, 2019* This is, without a doubt, a small revolution we are bringing to you! Matomo analyses activity on your site and produces charts, behaviour reports, traffic sources, and more…\ There is no better way to understand how your visitors interact with your site. Matomo is an extremely powerful tool with a wide range of capabilities. With the Matomo offering from ONETSOLUTIONS, you can track visitor activity on your blog, store, forum or website. Discover our plans now at [https://onetsolutions.net/web-hebergement](https://onetsolutions.net/web-hebergement) # MongoBleed (CVE-2025-14847): Unauthenticated MongoDB Memory Leak Source: https://blog.onetsolutions.net/en/mongobleed-cve-2025-14847 A flaw in MongoDB's network layer leaks fragments of server RAM — credentials, API keys, BSON — to unauthenticated attackers. *Published on December 1, 2025* **CVE-2025-14847 — nicknamed "MongoBleed".** Pre-authentication, reachable from the internet, public PoC in circulation. Treat any MongoDB instance exposed without the patch as compromised until proven otherwise. ## The short version MongoDB's network transport bundles a zlib decompressor that does not strictly validate the size of the decompressed payload. When a client advertises a compressed frame that is smaller than the buffer the server allocated for it, the server returns that buffer **without zeroing it out** — the leftover bytes are random heap data, in other words, chunks of RAM used by other requests. The attacker does not need **any account**: compression is negotiated during the handshake, before authentication. Repeating the trick lets them collect memory fragments request after request. ## What ends up leaking, in practice Researchers who looked at the bug report finding the following inside the leaked fragments: * plaintext database credentials, * administrative API keys, * environment variables, * fragments of BSON documents belonging to other users. In other words: a semi-random but repeatable window into the `mongod` process memory. ## Are you exposed? If your MongoDB instance: * accepts connections from the internet, **or** * accepts connections from a shared network (cloud LAN, multi-tenant VPC), **or** * sits behind an application that surfaces detailed errors back to clients, …treat the exposure as critical. A public PoC is circulating; in-the-wild exploitation has been confirmed. ## Patches to apply Upgrade to (at least) the patched version for your branch: | MongoDB branch | Minimum patched version | | - | - | | 8.2 | 8.2.3 | | 8.0 | 8.0.17 | | 7.0 | 7.0.28 | | 6.0 | 6.0.27 | | 5.0 | 5.0.32 | | 4.4 | 4.4.30 | ## Temporary mitigation If a patched restart is not immediately feasible: ```bash theme={null} # Force the negotiable compressor list to exclude zlib mongod --networkMessageCompressors=snappy,zstd ``` Or in `mongod.conf`: ```yaml theme={null} net: compression: compressors: snappy,zstd ``` Either way, while a patch is pending: lock down access to port `27017` to the strict minimum via firewall or Security Group rules. ## Check your version ```bash theme={null} mongosh --eval "db.version()" ``` Compare the output to the patched-version table above. ## What's next Once patched, assume any credentials that could have transited through that instance before the fix are compromised: rotate passwords, regenerate API keys, audit access logs. For any questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # New VPS Plans Source: https://blog.onetsolutions.net/en/new-vps-plans A new VPS lineup with DDR4 memory and Intel E5-2690v3 CPUs — up to 500% faster on CPU and 50% faster on RAM compared to our previous plans. New VPS Plans *Published on July 1, 2020* Just for you! With this new VPS lineup, we are bringing you a high-end service powered by the latest generation of memory (DDR4) and one or more Intel E5-2690v3 CPUs. Compared to our previous plans, you will get **up to 500% better CPU performance and 50% better memory performance**! ## What is DDR4? DDR4 is a significant evolution over DDR3. DDR4 modules deliver around 50% more performance, improved bandwidth, and lower power consumption. That is no small thing! ## What is the Intel E5-2690v3? It is a 12-core / 24-thread CPU at 2.6 GHz (3.5 GHz turbo). It only works with DDR4 memory. In dual-CPU configuration, it scores 27,308 on PerformanceTest V9 — see the score on [cpubenchmark](https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2690+v3+%40+2.60GHz\&id=2364\&cpuCount=2). It is a high-end, high-performance CPU. ## How do I get one? Head over to our website. Plans start at €2.99: [https://onetsolutions.net/vps-cloud-basic](https://onetsolutions.net/vps-cloud-basic) # nginx (CVE-2026-42533): Two Heap Overflows, and Why Patching the First Did Not Fix the Second Source: https://blog.onetsolutions.net/en/nginx-map-regex-cve-2026-42533 A buffer overflow in nginx's map-and-regex handling affects fifteen years of releases. If you patched for Nginx Rift in May, you are still exposed. *Published on August 12, 2026* **CVE-2026-42533 — buffer overflow when using `map` and regex.** Affects nginx **0.9.6 through 1.31.2**. Fixed in **1.30.4** (stable) and **1.31.3** (mainline). If you patched in May for Nginx Rift, that fix does **not** cover this one. ## The part most people got wrong Two heap overflows landed in nginx's script engine within a few months, and they look similar enough that they get confused. They are not the same bug, and — this is the part that matters — **the version that fixed one still runs the other**. | | Nginx Rift | This one | | - | - | - | | CVE | CVE-2026-42945 | **CVE-2026-42533** | | Component | `ngx_http_rewrite_module` | `map` + regex | | Affected | 0.6.27 → 1.30.0 | **0.9.6 → 1.31.2** | | Fixed in | 1.30.1+, 1.31.0+ | **1.30.4+, 1.31.3+** | | nginx severity | medium | **major** | Read the last two rows together. Rift was fixed in 1.30.1. CVE-2026-42533 affects everything up to 1.31.2. A server updated to 1.30.1 in May, ticked off as "patched", is squarely in range. If your last nginx update was prompted by the Rift coverage, you are not done. ## The flaw Both bugs come from the same design. nginx evaluates script expressions in two passes: the first measures how much buffer it needs, the second writes into it. When the state the engine relies on changes between the two passes, the write outruns the size that was measured, and the overflow lands on the heap. Rift got there through a stale flag. This one gets there through PCRE capture state: there is no save-and-restore around it, so captures from one evaluation clobber another. Triggering it needs a specific shape of configuration — a regex-based `map` block, and a directive that references both a regex capture and the map's output variable in the same expression. That is not exotic. It is a normal way to write a routing rule. Note the severity gap. nginx rates this **major** and rates Rift **medium**, while several third-party trackers scored Rift at CVSS 9.2. Vendor and third-party scores are measuring different things; the version ranges above are the part to act on, not the number. ## Sizing your exposure | Profile | Exposure | Action | | - | - | - | | nginx 1.30.4+ or 1.31.3+ | None | Nothing to do | | nginx between 1.30.1 and 1.31.2, "already patched for Rift" | **Critical** | Update now — this is the trap | | nginx below 1.30.1, no `map` with regex anywhere | Moderate | Both bugs apply; update at the next window | | Container images with a pinned nginx tag | **Often forgotten** | The published exploit chain was calibrated against Docker images | | Shared hosting where you do not manage nginx | Handled by the provider | Nothing to do on your side | That fourth row deserves emphasis. A pinned `nginx:1.30.1` in a Dockerfile does not update itself, and rebuilding is the only way it changes. The public full-chain proof of concept was tuned specifically for Docker deployments — base image, package snapshot and source revision. ## Checking and updating Find out what you are actually running, which is not always what your package manager thinks: ```bash theme={null} # The binary's own version nginx -v # Every nginx process on the box, in case an old one is still resident ps -eo pid,etime,cmd | grep "[n]ginx: master" ``` Debian, Ubuntu and derivatives: ```bash theme={null} sudo apt update && sudo apt install --only-upgrade nginx sudo systemctl restart nginx nginx -v ``` AlmaLinux, Rocky Linux and RHEL: ```bash theme={null} sudo dnf upgrade nginx sudo systemctl restart nginx nginx -v ``` A reload is not enough here. `nginx -s reload` starts new workers but the master process keeps running the old binary. Use `restart` so the whole process tree picks up the patched code, then confirm with `nginx -v`. For containers, rebuild rather than patch in place: ```bash theme={null} # Pull the rebuilt base image and recreate the container docker compose pull docker compose up -d # Confirm what the running container actually has docker compose exec web nginx -v ``` ## If you cannot update immediately There is no configuration flag that disables the bug. What you can do is remove the trigger: if a `map` block built on a regex feeds a variable that is used alongside a regex capture in the same directive, rewriting that expression closes the path until you patch. Find the candidates: ```bash theme={null} # map blocks whose source is a regex grep -rn "^\s*map\s" /etc/nginx/ -A 3 | grep -E "~\*?\s" # directives combining a capture ($1..$9) with another variable grep -rnE '\$[1-9].*\$[a-z_]+|\$[a-z_]+.*\$[1-9]' /etc/nginx/ ``` Treat this as a stopgap measured in days, not a fix. ## The wider lesson Two bugs of the same class, in the same engine, months apart, with overlapping-but-different version ranges. The failure mode is not "we did not patch" — it is "we patched, and assumed that settled it". When an advisory names a version, the useful question is not *did we update?* but *did we update past the range in this advisory?* They are different questions, and only the second one has an answer you can check. Our [guide to auditing and hardening nginx on a VPS](/en/audit-and-harden-nginx-on-a-vps) covers the routine that catches this class of thing before an advisory forces it. Questions about a server hosted with us? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # On-Demand NVIDIA GPU, Billed by the Minute Source: https://blog.onetsolutions.net/en/nvidia-gpu-on-demand Attach an NVIDIA L4 GPU to your High Performance VPS in one click, train or serve your models, then detach it — you only pay for the minutes used. On-demand NVIDIA cloud GPU on OnetSolutions *Published on July 14, 2026* Need GPU power without renting a dedicated GPU server by the month? You can now attach an NVIDIA GPU to your High Performance VPS in one click, and detach it as soon as you are done. ## NVIDIA L4: built for inference and compute The attached GPU is an NVIDIA L4 with 24 GB of GDDR6 VRAM and up to 242 TFLOPS in FP16 (485 TFLOPS in FP8). Standard NVIDIA drivers are pre-installed: CUDA and PyTorch work out of the box. ## €0.70 per hour, billed by the minute NVIDIA GPU pricing: €0.70 excl. VAT per hour, billed by the minute The GPU costs €0.70 excl. VAT per hour, billed by the minute, with no commitment. You attach it, you compute, you detach it — billing stops the minute the GPU is released. ## A GPU for every workload NVIDIA GPU use cases: training, LLM inference, 3D rendering Train a model, serve an LLM, render a 3D scene, or accelerate a data pipeline: the GPU joins your instance in a few minutes, only when you need it. ## How it works 1. Open your instance in the console and select **Attach a GPU**. 2. Restart the instance so the GPU is taken into account. 3. Work — then detach the GPU when you are finished. Billing stops to the minute. Ready to compute? [Discover the High Performance VPS with GPU](https://onetsolutions.net/en/gpu) or attach one directly from [your console](https://console.onetsolutions.net/dashboard). # One Click Apps: run 342 open source apps on your VPS Source: https://blog.onetsolutions.net/en/one-click-apps Deploy WordPress, Nextcloud, n8n or Gitea on your VPS from the console, with automatic HTTPS, daily backups and updates, without touching a terminal. *Published on September 6, 2026* Installing an application on a VPS used to mean an SSH session, a Docker Compose file, a reverse proxy and a TLS certificate to renew. One Click Apps removes those steps: you pick an application from a catalogue, you click, and it runs on your server a few minutes later. ## A platform on your server, not on ours One Click Apps installs a deployment platform on your own VPS. The applications run on your instance, with your resources and your data. You keep SSH access and root privileges: nothing prevents you from working directly on the machine. Installing the platform takes a few minutes and starts from the **One Click Apps** tab of your instance. It opens ports 80 and 443 for your applications, and restricts its own administration ports to our management servers. ## 342 applications across 38 categories The catalogue covers what a server is usually asked to do: content management, developer tools, automation, monitoring, AI, media, databases. WordPress, Nextcloud, Ghost, Gitea, Uptime Kuma, Vaultwarden, Umami and Activepieces are featured, but the full list holds 342 entries and refreshes automatically. Every application arrives preconfigured: passwords and keys are generated at deployment time, and you find them again in the application's **Overview** tab. ## HTTPS right away, your domain next As soon as it is deployed, the application is reachable over HTTPS on an automatically generated address, with a Let's Encrypt certificate. There is nothing to configure to start testing. When you are ready to move to your own domain name, add it in the **Domains** tab. If the domain's DNS zone is already managed at OnetSolutions within the same organization, the A record is created for you; otherwise the console tells you which IP address to point to and checks resolution before applying the domain. ## Daily backups, one-click restore Each application's data volumes are backed up once a day, with seven days of retention, without stopping the containers. The **Backups** tab lists the available archives, lets you trigger one on demand, and restores a volume to an earlier version. ## Updates you can see The console compares the deployed images with the ones published upstream, and flags the applications that have a newer version available. You start the update from the application page. The platform itself updates the same way, with an optional nightly auto-update. ## What you need * A VPS running Debian or Ubuntu * At least 2 vCPUs, 2 GB of RAM and 30 GB of disk * Nothing else: the feature is included with your VPS at no extra cost The number of applications per instance is limited by memory only. The console always shows the remaining RAM and refuses a deployment that would not fit. ## Getting started Open your instance in [the console](https://console.onetsolutions.net), go to **One Click Apps**, then install the platform. The documentation covers each step: [installation and requirements](https://help.onetsolutions.net/one-click-apps/overview), [deploying an application](https://help.onetsolutions.net/one-click-apps/deploy-an-app), [custom domain](https://help.onetsolutions.net/one-click-apps/custom-domain). One Click Apps is rolling out progressively. If the section does not appear on your instance yet, it is not enabled on your account yet. The applications you deploy and their data are yours to operate: their configuration, maintenance, updates and backups are your responsibility, and OnetSolutions support covers the instance, not what runs on it. The exact terms are set out in [the documentation](https://help.onetsolutions.net/one-click-apps/overview). The platform is built on [Coolify](https://coolify.io), an open source project released under the Apache 2.0 licence. # Install WordPress, PrestaShop or Drupal in Two Clicks Source: https://blog.onetsolutions.net/en/one-click-install-wordpress-prestashop-drupal Install WordPress, Drupal, PrestaShop and many other CMS in two clicks with Installatron — included for free in our web hosting plans. Install WordPress, PrestaShop or Drupal in Two Clicks *Published on July 20, 2019* We introduced cPanel in a previous post; today we are highlighting another tool we include for free in our web hosting plans: Installatron. This handy tool lets you install your CMS — WordPress, Drupal, PrestaShop, and many more — in just two clicks. Try it now by picking one of our web hosting plans: [https://onetsolutions.net/web-hebergement](https://onetsolutions.net/web-hebergement) # Blog Source: https://blog.onetsolutions.net/en/overview News, announcements, and guides from the OnetSolutions team What we ship, why we ship it, and how to get the most out of it. The OnetSolutions team writes here about new products, the systems that power your servers, and the vulnerabilities worth your attention — no fluff, straight to the point. ## Latest articles Linux 7.0, PostgreSQL 18 and support through 2031 — plus the breaking changes to check before you migrate. Deploy your instances on Windows Server 2025 with the licence included in the price — connect via RDP and get to work. An NVIDIA L4 on your VPS in one click, €0.70/hour billed by the minute. What the latest Debian release brings to your servers. ## Browse by topic New plans, operating systems, and features as they ship SSL, one-click installs, statistics, and everything cPanel Guides and comparisons to get the most out of your infrastructure Payment methods: cards, crypto, paysafecard, and more CVE analyses and mitigation guides for critical vulnerabilities Every product update and improvement, month by month ## Recent security advisories Our team publishes an analysis and mitigation guide whenever a critical vulnerability affects the ecosystem. Unauthenticated RCE in WordPress core — exploited in the wild, patch now A WordPress plugin shipped a deliberate admin backdoor — how to check your sites Linux kernel local privilege escalation and container escape — no workaround Linux kernel local privilege escalation — patch status and mitigation steps A vulnerability keeping you up at night? Our [enhanced VPS security guide](/en/enhanced-vps-linux-security) covers the tools and habits that protect your servers day to day. ## Go further Announcements, tips, and security alerts in real time Guides for VPS, web hosting, domains, and the API Manage instances, domains, hosting, and billing in one place # Pay with Bitcoin and Altcoins Source: https://blog.onetsolutions.net/en/pay-with-bitcoin-and-altcoins ONETSOLUTIONS is one of the first hosting providers to accept Bitcoin and altcoin payments to make ordering and renewing your services easier. Pay with Bitcoin and Altcoins *Published on July 20, 2019* ONETSOLUTIONS is one of the first hosting providers to accept Bitcoin and altcoin payments.\ We do everything we can to make paying for and renewing your services as easy as possible. ***How do I pay with Bitcoin?*** If you want to pay with Bitcoin, simply choose "Bitcoin" at checkout.\ Once you have the payment address and amount, you can send the payment. You can also scan the QR code we display on the payment page. The payment will be confirmed within minutes, once the network has verified the transaction. # Pay with Paysafecard Source: https://blog.onetsolutions.net/en/pay-with-paysafecard Pay for your hosting, domain name, web radio or VPS with a PAYSAFECARD prepaid card — now accepted at ONETSOLUTIONS. Pay with Paysafecard *Published on July 20, 2019* Got a PAYSAFECARD prepaid card? It is now accepted as a payment method at ONETSOLUTIONS for all of our services. Each card carries a balance you can use to pay for your hosting, domain name, web radio and even your private server. At checkout, just select "PAYSAFECARD" as your payment method. If you have any questions about this payment method, feel free to email us at "contact at onetsolutions dot net". See you soon at ONETSOLUTIONS! # React2Shell (CVE-2025-55182): Unauthenticated RCE in React Server Components Source: https://blog.onetsolutions.net/en/react2shell-cve-2025-55182 Unsafe deserialisation in React 19's Flight protocol allows arbitrary code execution on the server. CVSS 10.0, active exploitation. *Published on December 10, 2025* **CVE-2025-55182 — "React2Shell" — CVSS 10.0.** Remote code execution, unauthenticated, on Next.js servers and other frameworks built on React 19 + Server Components. Active exploitation in the wild. ## Why this one is serious If you run **React 19 with Server Components** (which includes most recent Next.js apps in App Router mode), your server executes deserialisation code for the Flight protocol on every request. Flight serialises server components between Node.js and the browser — and that is exactly where the bug lives. By crafting a malicious Flight request, an **unauthenticated** attacker can: 1. Manipulate internal objects used for module resolution, 2. Hijack Flight callbacks toward sensitive Node.js primitives, 3. End up executing shell commands on the host. ## What it gets you, as an attacker Once RCE is achieved, the playbook is the usual brutal one: * Theft of environment variables and server-side secrets, * Lateral movement to internal services reachable from the pod or VM, * Persistence via cron, daemon, or a backdoor injected in the bundle, * Cryptominer or C2 deployment on the cloud infrastructure. Several state-affiliated threat groups have been observed exploiting the flaw. ## Versions to upgrade ### React Server Components The packages `react-server-dom-webpack`, `react-server-dom-parcel`, and `react-server-dom-turbopack`, in versions 19.0.0 → 19.2.0, must move to: * `19.0.1` * `19.1.2` * `19.2.1` ### Next.js (App Router) Upgrade to the patched version closest to your current branch: | Next.js branch | Patched version | | - | - | | 15.0 | 15.0.5 | | 15.1 | 15.1.9 | | 15.2 | 15.2.6 | | 15.3 | 15.3.6 | | 15.4 | 15.4.8 | | 15.5 | 15.5.7 | | 16.0 | 16.0.7 | After upgrading, **redeploy all affected services** — a plain `pnpm install` without a rebuild is not enough. ## Immediate response 1. **Inventory**: list every React 19 / Next.js App Router workload in your infrastructure (production, staging, PR previews…). 2. **Patch**: apply the patched versions everywhere. 3. **Contain**: restrict public access to services that cannot be patched immediately. 4. **Investigate**: audit logs for suspicious execution, rotate exposed secrets (API keys, session tokens, environment variables), increase monitoring on unpatched hosts until the migration is complete. ## Check your versions ```bash theme={null} # Installed versions pnpm list react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next # On a Next.js workspace npx next --version ``` ## Resources For technical assistance, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # RediShell (CVE-2025-49844): Redis Lua Sandbox Escape to RCE Source: https://blog.onetsolutions.net/en/redishell-cve-2025-49844 A malicious Lua script exploits a use-after-free in Redis's embedded engine to execute native code on the host. Public PoC. *Published on October 21, 2025* **CVE-2025-49844 — "RediShell".** A Redis client with access to the `EVAL` command can escape the Lua sandbox and run native code on the host. On any Redis that is misconfigured (no `requirepass`, exposed to LAN or internet), the attack effectively becomes pre-authentication. ## The mechanics Redis's embedded Lua engine theoretically isolates user scripts in a sandbox. The bug is a two-step affair: 1. **Memory corruption.** A specially-crafted Lua script manipulates Lua's garbage collector to free an object that is still referenced elsewhere. 2. **Escape.** The resulting use-after-free lets the attacker break out of the Lua interpreter and run code natively inside the `redis-server` process. From there, the attacker owns the Redis process with its rights. On most deployments, those rights are enough to read data, reach the container or VM filesystem, and attempt lateral movement to other services reachable from the host. ## Why the "authenticated" qualifier is misleading The advisory talks about an authenticated attacker — but in practice: * Many Redis instances run with no `requirepass`, sitting on networks assumed to be "trusted". * Others store credentials in plaintext inside backups, Docker images, or leaked environment variables. * A plain SSRF in an application that talks to an internal Redis is enough to look "authenticated" from Redis's perspective. Bottom line: the real exposure is broad. ## Patches Upgrade Redis to (at least) the patched version for your branch: | Redis branch | Minimum patched version | | - | - | | 6.2 | 6.2.20 | | 7.2 | 7.2.11 | | 7.4 | 7.4.6 | | 8.0 | 8.0.4 | | 8.2 | 8.2.2 | ## Mitigation if you cannot patch right away Disable the Lua commands through Redis ACLs. Not ideal (some apps depend on them) but it closes the attack path: ```redis theme={null} # For the default user ACL SETUSER default -eval -evalsha -fcall -fcall_ro -function # Verify ACL LIST ``` On the network side: * Bind Redis to `127.0.0.1` or to a strictly internal network (`bind` in `redis.conf`). * Enable `requirepass` or named ACLs. * Block port `6379` at the firewall for everything except your application clients. ## Check your version ```bash theme={null} redis-cli INFO server | grep redis_version ``` ## Takeaways * Patching is the right answer. If you defer: ACL `-eval` + network restriction, in the meantime. * Use the restart to tighten configuration: binding, requirepass, renaming dangerous commands. * A PoC is public, exploitation is trivial once `EVAL` is reachable — don't sit on it. For help, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # RegreSSHion (CVE-2024-6387): Unauthenticated RCE in OpenSSH Source: https://blog.onetsolutions.net/en/regresshion-cve-2024-6387 A regression of a 2006 OpenSSH bug reappears in recent versions and allows remote code execution as root, without authentication. *Published on July 2, 2024* **CVE-2024-6387 — "RegreSSHion".** Race condition in `sshd`'s `SIGALRM` handler, triggerable remotely, no credentials needed. The end goal: `root` on the machine. Exploitation is slow (days rather than hours on most targets) and requires a payload tailored to the binary — but the public PoC proved it is entirely feasible. ## The story behind the bug `CVE-2006-5051` was fixed in 2006. In 2020, an OpenSSH logging-code refactor reintroduced the same condition. Nobody spotted it for four years. Qualys dug it back up in June 2024 — hence the name "RegreSSHion", a contraction of *regression* and *SSH*. ## The mechanics `sshd` enforces a maximum delay (`LoginGraceTime`, 120 seconds by default) for a client to complete authentication. When that delay expires, the kernel sends `SIGALRM` to the process, which fires a handler called `sigdie`. That handler calls logging functions (`syslog()`, etc.) which are **not** *async-signal-safe* — they can take locks, allocate memory, touch global structures. If the attacker times the timer expiry precisely while `sshd` is itself manipulating those structures (typically during a concurrent logging operation), they trigger heap corruption. With enough attempts and a finely-tuned payload, that corruption turns into code execution in the privileged `sshd` process. ## Why the attack is slow without being theoretical * It takes **tens of thousands of attempts** to win the race. * Each attempt must wait for `LoginGraceTime` to expire. * The payload must match the exact OpenSSH version **and** target libc. On 32-bit glibc Debian, Qualys demonstrated exploitation in \~6-8 hours. On a recent 64-bit, they estimate 6-8 days per target. That is too slow for *spray and pray*, but well within reach for a targeted attack — and the exploit is becoming more industrialised. ## Are you affected? Versions affected (Linux glibc): * OpenSSH 4.4p1 → 8.5p1: not affected (the regression was introduced later). * OpenSSH **8.5p1 → 9.7p1**: **vulnerable**. * OpenSSH 9.8p1 and later: fixed. Quick check: ```bash theme={null} ssh -V ``` ## Patches Track your distribution's advisory: | Distribution | Patched version | | - | - | | Ubuntu Jammy (22.04) | `1:8.9p1-3ubuntu0.10` | | Ubuntu Mantic (23.10) | `1:9.3p1-1ubuntu3.6` | | Ubuntu Noble (24.04) | `1:9.6p1-3ubuntu13.3` | | Debian Bullseye (11) | `1:8.4p1-5+deb11u3` | | Debian Bookworm (12) | `1:9.2p1-2+deb12u3` | | Debian Sid | `1:9.7p1-7` | ## Temporary mitigation If you cannot patch right away, you can remove the race window by setting `LoginGraceTime 0` in `/etc/ssh/sshd_config`: ```text theme={null} LoginGraceTime 0 ``` Then reload: ```bash theme={null} sudo systemctl reload ssh ``` This mitigation **exposes you to a trivial denial of service**: an attacker can open TCP connections that never authenticate and exhaust `sshd`'s pre-auth slots. Use it only as a last resort, until the patch lands. Surface-reduction measures you can apply without losing service: * Restrict SSH access at the firewall to known IPs or ranges. * Use `Match` + `AllowUsers` to narrow the reachable account surface. * Add `fail2ban` on the auth log to slow attempt bursts. ## Verify after patching ```bash theme={null} # The version must be beyond the vulnerable ranges sudo sshd -V 2>&1 | head -1 ``` ## Wrap-up A quiet regression, exploitable, and a reminder that old patches deserve regression tests. Patching is fast, the operational cost is minimal, and the residual risk of unauthenticated root RCE more than justifies not waiting. For questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # Hardening WordPress After wp2shell: Seven Measures That Actually Matter Source: https://blog.onetsolutions.net/en/secure-wordpress-after-wp2shell Two critical WordPress incidents in a fortnight, from opposite directions. A practical checklist: auto-updates, plugin hygiene, least privilege, and compromise checks. Hardening WordPress after wp2shell: core auto-updates, fewer plugins, no PHP execution in uploads *Published on August 8, 2026* July 2026 delivered two WordPress incidents from opposite directions. [wp2shell](/en/wp2shell-cve-2026-63030) was a flaw in core itself — unauthenticated remote code execution, exploited within hours of disclosure. The [ARVE backdoor](/en/arve-backdoor-cve-2026-18072) was not a flaw at all, but a deliberate compromise of a plugin's distribution channel. They defeat different defences. Plugin discipline would not have saved you from wp2shell. Prompt updating is what *delivered* the ARVE backdoor to anyone who received it. A checklist that only handles one shape of incident is not a checklist. Here is what holds up against both, ordered by what it actually buys you. ## 1. Automatic updates on core, on purpose Minor core releases carry the security fixes, and they are designed to be safe to apply blind. WordPress.org pushed forced updates for wp2shell — but only to sites where auto-updates were enabled and core files were writable. ```php theme={null} // wp-config.php — minor releases only, the default and the right choice define( 'WP_AUTO_UPDATE_CORE', 'minor' ); ``` Verify what is actually in effect, rather than what you believe you configured: ```bash theme={null} wp config get WP_AUTO_UPDATE_CORE wp core version ``` Sites deployed from Git with read-only core files silently opt out of this. If your deployment pipeline owns `wp-includes`, then your pipeline owns patching — and it needs to run on security releases, not on your sprint cadence. ## 2. Delay plugin updates, do not disable them This is the one counter-intuitive item, and the ARVE incident is the argument for it. Plugin backdoors are caught fast — this one in under two hours — but they are caught *after* publication. Applying every plugin update the minute it lands puts you first in line for a compromised release. Never applying them leaves you exposed to ordinary vulnerabilities, which are far more common. The middle ground: automatic updates for plugins, deliberately lagging by a few days, with security releases exempt from the delay. Whatever tool you use to manage sites at scale, this is the setting to look for. If you manage a handful of sites by hand, the same logic applies with less machinery: check for updates weekly, apply security ones immediately and the rest at your next pass. ## 3. Fewer plugins Every plugin is a standing grant of code execution to a third party, renewed on every update. The strongest control is a shorter list. ```bash theme={null} # Everything installed, active or not — deactivated plugins still sit on disk wp plugin list --fields=name,status,version,update # Remove what is inactive wp plugin list --status=inactive --field=name | xargs -r -n1 wp plugin delete ``` Prefer plugins with several maintainers over single-maintainer ones. A plugin maintained by one person is one account away from what happened to ARVE. ## 4. Least privilege on accounts The wp2shell chain ends by creating an administrator. Plenty of attacks end by *using* one that was lying around. Most people who log into a WordPress site do not need to install plugins. Editor is enough to publish. Administrator should be a role held by one or two people, not the default for everyone with a login. ```bash theme={null} # Who holds administrator rights, and since when wp user list --role=administrator --fields=ID,user_login,user_email,user_registered # Downgrade someone who only needs to publish wp user set-role 12 editor ``` Turn on two-factor authentication for the accounts that remain. On the [OnetSolutions console](https://help.onetsolutions.net/console/security) it protects the hosting account itself, which is the layer underneath the site. ## 5. Cut off code execution in uploads A web shell has to land somewhere, and `wp-content/uploads` is where it usually lands. That directory holds images and PDFs. It has no business executing PHP. For nginx: ```nginx theme={null} # In the site's server block location ~* /wp-content/uploads/.*\.php$ { deny all; } ``` For Apache, an `.htaccess` at the root of `wp-content/uploads`: ```apache theme={null} Require all denied ``` This is a cheap, near-zero-risk control that turns a large class of successful exploits into a file sitting harmlessly on disk. If your hosting lets you pick the [PHP version and handler](https://help.onetsolutions.net/web-hosting/php-version), check this rule survives the configuration. ## 6. Disable file editing from the dashboard The dashboard's built-in plugin and theme editor lets anyone with administrator rights write PHP straight to disk. It is a convenience worth almost nothing and an escalation path worth a great deal. ```php theme={null} // wp-config.php define( 'DISALLOW_FILE_EDIT', true ); ``` If you want to go further, `DISALLOW_FILE_MODS` also blocks installing and updating plugins and themes from the dashboard — appropriate for sites deployed from a repository, and disruptive for sites managed by hand. Note that it disables automatic plugin updates too, so only use it where the pipeline handles updates. ## 7. Backups you have restored at least once Every incident response above ends the same way: restore from a backup predating the compromise. That step only works if the backup exists, reaches far enough back, and actually restores. Three properties matter, and only the first is usually checked: * **The backup runs.** Easy to verify, and where most people stop. * **Retention outlives detection.** A compromise found in September needs an August backup. Seven days of retention is not a security backup, it is an undo button. * **The restore has been tested.** Restore to a staging site once. It is the only way to learn that the database dump was truncated, before you need it. Both [shared hosting backups](https://help.onetsolutions.net/web-hosting/backup) and [VPS snapshots](https://help.onetsolutions.net/vps/snapshot) are available from the console. Take a manual snapshot before every core update — it costs a minute and it is the rollback point you will want. ## A five-minute check, right now If you do nothing else after reading this, run these four: ```bash theme={null} # 1. Is core on a patched version? 6.9.5, 7.0.2 or later wp core version # 2. Any administrator account you cannot name? wp user list --role=administrator --fields=user_login,user_email,user_registered # 3. Any PHP written under wp-content in the last 30 days? find wp-content -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %p\n" | sort -r | head -20 # 4. Is the ARVE plugin present? wp plugin get advanced-responsive-video-embedder --field=version 2>/dev/null || echo "absent" ``` Four commands, and they cover the two incidents of the past month plus the most common signs of a site that was compromised earlier and never noticed. None of this makes a site unbreakable. It shortens the list of things that break it, and it makes the ones that get through easier to spot and cheaper to recover from. That is what hardening is. Questions about a site hosted with us? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # Protect Your Data with Automated Backups Source: https://blog.onetsolutions.net/en/secure-your-data-with-automated-backups Two backup options to protect your data: automated daily backups (€4.99/mo) and on-demand snapshots (€2.99/mo) — encrypted, off-site, and flexible. Protect Your Data with Automated Backups *Published on June 28, 2023* At OnetSolutions, the security of your data is our top priority. We understand how important it is to preserve the integrity of your information and keep it available no matter what. That is why we offer two advanced backup options: automated backups and on-demand snapshots. In this article we cover these features in detail — their reliability, accessibility, and how effectively they protect your data. ## Total peace of mind For just €4.99 excl. VAT per month, our automated backup option gives you complete peace of mind. This secure solution backs up your data off-site — more than 100 kilometres from the data centre hosting your VPS. That geographic distance provides extra protection against disaster or data loss. We take security seriously, so your backups are encrypted to keep your sensitive information confidential. We use advanced encryption protocols to ensure that only authorised people can access your data. The OnetSolutions automated backup option is also highly flexible. There is no size limit, so you can protect even the largest datasets. Backups are taken daily over a rolling 7-day window, giving you several recovery points so you can restore your data to an earlier state if needed. ## Snapshots of your data, on demand To complement automated backups, we also offer on-demand snapshots. For just €2.99 excl. VAT per month, this feature lets you take a snapshot of your data at any time. Snapshots are point-in-time copies of your server's state. The advantage of on-demand snapshots is the flexibility they give you in managing your data. You can take a snapshot before making major configuration changes or applying critical updates. If something goes wrong, you can quickly restore your server to the exact state of the chosen snapshot. Snapshots are stored securely and can be kept for as long as you need. That lets you roll back to any point in time, giving you greater data resilience. *** At OnetSolutions, we are committed to providing advanced backup solutions to protect your valuable data. With our automated backup option and on-demand snapshots, you have all the tools you need to keep your information secure and available. For just €4.99 excl. VAT per month, automated backups give you optimal protection thanks to geographically distant backups, secure encryption, and a rolling 7-day retention period. For just €2.99 excl. VAT per month, on-demand snapshots let you take point-in-time copies of your data whenever you want — adding extra flexibility to how you manage your infrastructure. We understand how critical data security is for your business. That is why we provide these advanced backup options — for protection, availability, and recovery when you need it. Don't take chances with your valuable data. Choose OnetSolutions automated backups and on-demand snapshots and enjoy total peace of mind knowing your information is safe. Get in touch today to learn more about our backup solutions and pick the one that best fits your needs. We are here to help you protect your critical data. # Security advisories Source: https://blog.onetsolutions.net/en/security-advisories Every critical vulnerability we have analysed, newest first. Subscribe to the RSS feed to get the next one. We publish an analysis and a mitigation guide whenever a critical vulnerability affects the stacks our customers run — Linux kernel, web servers, databases, container orchestration, WordPress. Subscribe to this page's RSS feed with the button above. New advisories land there as they are published, which beats remembering to check. The ebtables SNAT target rewrites the ARP sender address without checking that the target memory is writable, and can end up writing into the page cache. Where unprivileged user namespaces are allowed, any local account can build the setup it needs. In CISA's KEV catalog since 18 September. No fix yet on Ubuntu 22.04 and 24.04: block the `ebt_snat` module. [Read the full advisory](/en/ebtables-snat-cve-2026-53266) A heap overflow in nginx's two-pass script engine, reachable through a regex-based `map` feeding a directive that also uses a regex capture. Affects 0.9.6 through 1.31.2. The trap: the May fix for Nginx Rift (CVE-2026-42945, fixed in 1.30.1) does not cover this one. Update to 1.30.4 or 1.31.3. [Read the full advisory](/en/nginx-map-regex-cve-2026-42533) Symlink mishandling in the LiteSpeed cPanel plugin lets an account with nothing more than FTP access escalate to root on shared hosting running CloudLinux or CageFS. In CISA's KEV catalog since 15 June. Fixed in LiteSpeed WHM plugin 5.3.2.1. [Read the full advisory](/en/litespeed-cpanel-cve-2026-54420) A routing confusion in the WordPress REST API batch processor, chained with an SQL injection, gives full site takeover without any credentials. Added to CISA's KEV catalog on 21 July and exploited in the wild. Patched in 6.9.5 and 7.0.2. [Read the full advisory](/en/wp2shell-cve-2026-63030) Not a bug but an intent: version 10.8.7 of a WordPress plugin with 20,000 installs shipped a hardcoded administrator backdoor. Caught in under two hours, and pulled from WordPress.org. There is no fixed version — remove the plugin. [Read the full advisory](/en/arve-backdoor-cve-2026-18072) A use-after-free on the futex priority-inheritance path, present since 2011, turns any local user into root in about five seconds and escapes containers to the host. No runtime mitigation exists: patch the kernel and reboot. [Read the full advisory](/en/ghostlock-cve-2026-43499) A flaw in the kernel's cryptographic subsystem, reachable through the AF\_ALG interface, lets locally-running code walk out with root. Container escape included. A module blacklist mitigates it until the kernel patch lands. [Read the full advisory](/en/copy-fail-cve-2026-31431) Unsafe deserialisation in React 19's Flight protocol allows arbitrary code execution on the server, unauthenticated. A perfect 10.0, with active exploitation. [Read the full advisory](/en/react2shell-cve-2025-55182) MongoDB's network layer leaks fragments of server memory to unauthenticated clients — credentials, API keys and BSON documents among them. [Read the full advisory](/en/mongobleed-cve-2025-14847) A malicious Lua script escapes the Redis sandbox through a use-after-free in the embedded engine and runs native code on the host. Public proof of concept. [Read the full advisory](/en/redishell-cve-2025-49844) Four chained flaws in the Ingress NGINX controller take an unauthenticated attacker from a request to code execution, and from there to the whole cluster. [Read the full advisory](/en/ingress-nightmare-kubernetes-2025) Four chained CUPS flaws let an attacker register a malicious printer on your network and obtain code execution the moment someone prints to it. [Read the full advisory](/en/cups-rce-2024) A 2006 bug reintroduced by a regression: recent OpenSSH versions allow remote code execution as root, with no authentication. [Read the full advisory](/en/regresshion-cve-2024-6387) A backdoor deliberately planted in xz-utils 5.6.0 and 5.6.1, targeting OpenSSH through systemd. Caught before it reached stable distributions. [Read the full advisory](/en/xz-backdoor-cve-2024-3094) Hardening your servers day to day is a different exercise from reacting to a CVE. Our [enhanced VPS security guide](/en/enhanced-vps-linux-security) covers the tools and habits, and the [WordPress hardening checklist](/en/secure-wordpress-after-wp2shell) covers the web side. # How Server Location Impacts Website Performance Source: https://blog.onetsolutions.net/en/server-location-and-website-performance Why server location matters for performance, availability, and SEO — and how to pick the right one for your website. How Server Location Impacts Website Performance *Published on February 4, 2024* The location of the server hosting your website can have a significant impact on its performance, load speed, and search engine ranking. In this article, we look at why server location matters and how to pick the best location for your hosting to optimise your website's performance. ### 1. Geographic distance and latency Geographic distance between the server and end users directly affects latency — the time it takes for data to travel between the server and the user. The greater the distance, the higher the latency, which translates to longer page loads. Picking a server closer to your target audience can reduce latency and improve overall site performance. ### 2. Regional availability Server location can also affect the regional availability of your website. Some Internet Service Providers (ISPs) and Content Delivery Networks (CDNs) may have points of presence in certain parts of the world, which can speed up content delivery to users in those regions. By picking a server location that matches the regions where most of your users live, you can improve availability and accessibility. ### 3. Impact on SEO Search engines such as Google factor page-load speed into their ranking algorithms. A website hosted on a server close to its target audience can therefore benefit from a better ranking in search results. Picking an optimal server location can improve your SEO and increase your online visibility. ### 4. What to consider when picking a server location When picking a server location, here are a few factors to consider: * The geographic location of your target audience. * The regions where your main business partners or suppliers are located. * The locations of major CDN data centres. * Legal and regulatory data-storage requirements in certain regions. ### Conclusion Server location is a critical factor that can significantly impact the performance, availability, and SEO of your website. By picking a server location that matches your target audience and your business strategy, you can optimise performance and offer a better user experience to your online visitors. If you want to maximise your website's performance and improve your search ranking, picking the right server location from the start is essential. # Simplified Automation with Ansible Source: https://blog.onetsolutions.net/en/simplified-automation-with-ansible What Ansible is, how it works, and how its agentless, YAML-based approach can simplify deployment and configuration management. Simplified Automation with Ansible *Published on October 7, 2023* Automation has become a cornerstone of modern systems administration, letting administrators efficiently manage large infrastructures while reducing human error. One of the most powerful and popular tools for automating repetitive tasks and configuration management is Ansible. In this article, we cover what Ansible is, how it works, and how it can simplify life for sysadmins and developers. ## What is Ansible? Ansible is an open-source automation tool for configuration management, application deployment, and task orchestration on remote servers. Developed by Red Hat, Ansible is widely used in the industry for its simplicity and flexibility. It uses a declarative approach: you describe the desired state of your infrastructure, and Ansible makes sure that state is reached. ## How does Ansible work? Ansible uses an agentless architecture, which means there is no agent to install on the remote nodes you want to automate. Instead, Ansible connects to servers over SSH (or other protocols if needed) and runs modules on those servers to perform specific tasks. The benefits of this approach are simplicity, security, and ease of setup. ## Ansible key concepts ### Inventory The Ansible inventory is a file or set of files that lists the servers or nodes you want to manage. You can organise nodes into groups to simplify management. ### Playbooks Playbooks are YAML files that describe the tasks you want to automate. They specify which actions should be performed on which machines. Ansible runs these playbooks to apply your infrastructure and configurations. ### Modules Modules are scripts or programs written in Python or other languages. They are used to perform specific tasks on remote servers. Ansible has a vast library of modules for common tasks such as installing software, managing users, configuring firewalls, and more. ## Benefits of Ansible 1. **Simplicity**: Ansible is known for being easy to learn. Ansible playbooks are written in YAML — a human-readable format — making it easier to author and manage automated tasks. 2. **Agentless**: no need to install agents on remote nodes, which simplifies management and security. 3. **Extensibility**: you can extend Ansible by writing your own custom modules or by using ready-to-use Ansible roles and collections. 4. **Large community**: Ansible has an active community that shares playbooks, modules, and tips — making it easier to troubleshoot and learn. ## Common use cases Ansible can be used for many use cases, including: * **Server provisioning**: automate the configuration of new servers. * **Configuration management**: ensure servers are configured according to your specifications, maintaining consistency. * **Application deployment**: deploy applications and make sure they are up to date and running correctly. * **Orchestration**: automate complex workflows involving multiple servers and tasks. ## Conclusion Ansible is a powerful and versatile automation tool that simplifies configuration management and task automation across IT infrastructures. Whether you are a sysadmin, developer, or security professional, Ansible can help you save time, reduce errors, and improve consistency across your infrastructure. Start exploring Ansible and see how it can simplify your work life by automating repetitive tasks and strengthening configuration management on your servers. # SPF, DKIM, DMARC and Reverse DNS: Getting Your VPS Mail Out of the Spam Folder Source: https://blog.onetsolutions.net/en/spf-dkim-dmarc-reverse-dns-vps-mail-server The four checks Gmail and others run before accepting your mail, how to pass them on a Debian or Ubuntu VPS, and how to prove it with dig. *Published on September 24, 2026* Since February 2024, Gmail has required **every** sender to its personal accounts to authenticate with SPF or DKIM, to have valid forward and reverse DNS for the sending address, and to use TLS. Above 5,000 messages a day, it takes SPF **and** DKIM, plus DMARC. Yahoo published rules along the same lines. Since November 2025, Google no longer just files non-compliant mail as spam: it applies temporary and permanent rejections. A mail server on a VPS is no exception. Here are the four records that make the difference, in the order to set them, and how to check each one. ## What the receiving server checks | Check | Question asked | Record | | - | - | - | | Reverse DNS | Does the connecting IP have a name, and does that name point back to it? | `PTR` on the IP, `A` on the name | | SPF | Is this IP allowed to send for this domain? | `TXT` on the domain | | DKIM | Was the message signed by the domain, and left unaltered? | `TXT` on `._domainkey` | | DMARC | Does the domain in the visible `From:` match the one that passed SPF or DKIM, and what if not? | `TXT` on `_dmarc` | The examples below use `example.com`, the server `mail.example.com` and the address `203.0.113.42`. Substitute your own. ## 0. First: outbound port 25 None of this matters if your server cannot reach anyone else. Many providers block outbound port 25 by default. We do: outbound ports **25, 465 and 587** are closed on every new VPS, and open on request for reasonable use (a personal mail server, application notifications), never for bulk sending. The details are in the [network documentation](https://help.onetsolutions.net/vps/network#email-ports). Test from the VPS: ```bash theme={null} # Should report "succeeded" or "open"; a timeout means it is blocked nc -vz -w 5 gmail-smtp-in.l.google.com 25 ``` ## 1. Hostname, A record and reverse DNS Three values must agree: the name your server announces in its `HELO`, the `A` record for that name, and the reverse DNS (`PTR`) of the IP address. ```bash theme={null} # The name Postfix announces in its HELO postconf myhostname # expected: myhostname = mail.example.com ``` If it is wrong, fix it: ```bash theme={null} sudo postconf -e 'myhostname = mail.example.com' sudo systemctl reload postfix ``` On the DNS side you need an `A` for `mail.example.com` pointing to `203.0.113.42`, and the domain's `MX` pointing to `mail.example.com`. The reverse DNS does not live in your zone: the IP belongs to your provider, and only they can set it. With us, it is set from the console; the steps are in the [Reverse DNS documentation](https://help.onetsolutions.net/vps/reverse-dns). If we host your domain's DNS zone, the **Domain** tab on your instance, profile **A website and email**, writes the `mail` `A` record, the `MX` (priority 10 to `mail.example.com`), the SPF and DMARC records described below, and sets the IP's reverse DNS. A preview shows everything before it is written, including your current `MX` records if they are about to be replaced. See [the announcement](/en/domain-linked-to-vps) and the [documentation](https://help.onetsolutions.net/vps/redirect-my-domain). Only DKIM is left to you: section 3. Check that forward and reverse agree: ```bash theme={null} dig +short -x 203.0.113.42 # expected: mail.example.com. dig +short A mail.example.com # expected: 203.0.113.42 dig +short MX example.com # expected: 10 mail.example.com. ``` ## 2. SPF: who may send A single `TXT` record at the root of the domain. For a server that is both the website and the mail server: ```text theme={null} example.com. IN TXT "v=spf1 a mx -all" ``` `a` authorises the address in `example.com`'s `A` record, `mx` those of the `MX` hosts, and `-all` states that nothing else sends for this domain. This is the record the console's email profile writes. If another service also sends on your behalf (hosted mailbox, newsletter tool), add its `include:` mechanism to **the same** record, not a second one. ```bash theme={null} dig +short TXT example.com | grep spf1 # exactly one line expected ``` SPF checks the envelope address (`MAIL FROM`), not the `From:` header your recipient reads. DMARC, section 4, is what ties the two together. ## 3. DKIM: sign what leaves DKIM is the one of the four the console cannot write for you: the private key is generated on your server and must never leave it. You only publish the public key. On Debian or Ubuntu with Postfix, OpenDKIM does the job: ```bash theme={null} sudo apt install opendkim opendkim-tools # 2048-bit RSA key pair, selector "s2026" sudo opendkim-genkey -b 2048 -d example.com -D /etc/dkimkeys -s s2026 -v sudo chown opendkim:opendkim /etc/dkimkeys/s2026.private ``` This produces `s2026.private` (the private key) and `s2026.txt` (the DNS record to publish). The selector is any name you like; putting the year in it makes rotation easier later. In `/etc/opendkim.conf`, set the domain, selector and key, and replace the existing `Socket` line with a local port, which Postfix can reach even from its chroot: ```text theme={null} Domain example.com Selector s2026 KeyFile /etc/dkimkeys/s2026.private Socket inet:8891@localhost ``` Then plug Postfix into the milter: ```bash theme={null} sudo postconf -e 'smtpd_milters = inet:localhost:8891' sudo postconf -e 'non_smtpd_milters = $smtpd_milters' sudo postconf -e 'milter_default_action = accept' sudo systemctl restart opendkim postfix ``` Publish the contents of `s2026.txt` as a `TXT` record on `s2026._domainkey.example.com`: ```bash theme={null} sudo cat /etc/dkimkeys/s2026.txt ``` ```text theme={null} s2026._domainkey.example.com. IN TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqh..." ``` A 2048-bit key exceeds the 255 characters a single `TXT` string allows, so the file splits it into several quoted strings. Together they form one record, not several. Once published, check that it comes back whole and matches the private key: ```bash theme={null} dig +short TXT s2026._domainkey.example.com sudo opendkim-testkey -d example.com -s s2026 -k /etc/dkimkeys/s2026.private -vvv # expected at the end of the output: "key OK" ``` A `key not secure` line before it only means the zone is not DNSSEC-signed. It does not stop DKIM from working. ## 4. DMARC: tie it together and say what to do on failure DMARC requires the domain in the `From:` header to align with the one that passed SPF or DKIM, publishes what the receiver should do otherwise, and says where to send you reports. ```text theme={null} _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com" ``` * `p=quarantine`: a failing message goes to spam. `p=none` asks for nothing; `p=reject` has it refused. * `rua=`: the address that receives daily aggregate reports (compressed XML) from the large providers. **That mailbox must exist.** This is the record the console's email profile sets. It assumes everything sending as you already passes SPF or DKIM. If other services send for your domain and you are not sure of them, start with `p=none`, read the reports for a week or two, then move up. ```bash theme={null} dig +short TXT _dmarc.example.com ``` ## 5. Check end to end The records can be right and the message still fail. Send a real message to a Gmail address, **through your own Postfix** so it gets signed: ```bash theme={null} sudo apt install swaks swaks --server 127.0.0.1 --from test@example.com --to you@gmail.com ``` In Gmail, open the message, the **⋮** menu, **Show original**. You should see `PASS` on all three lines: SPF, DKIM and DMARC. The detail is in the `Authentication-Results` header: ```text theme={null} Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=s2026 ... spf=pass (google.com: domain of test@example.com designates 203.0.113.42 as permitted sender) ... dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com ``` On the server, OpenDKIM's log confirms the signature: ```bash theme={null} sudo journalctl -u opendkim --since "10 min ago" | grep "DKIM-Signature field added" ``` ## Common pitfalls **Two SPF records.** A domain must carry exactly one. With two `TXT` records starting with `v=spf1`, the result is a permanent error and SPF fails for everyone. Merge them. **More than ten DNS lookups.** Every `include`, `a`, `mx`, `ptr`, `exists` and `redirect` costs one query, and nested `include`s count too. Past ten, SPF returns a permanent error. Three or four third-party services are enough to get there. **`-all` or `~all`.** `-all` (fail) says nothing else sends; `~all` (softfail) says it without insisting. Some receivers reject on an SPF fail before even evaluating DKIM, which penalises forwarded mail. If your domain's messages are often forwarded, `~all` with DKIM and DMARC in place is a common compromise. **DMARC at `p=none` forever.** `p=none` is for watching. It meets the letter of the requirements but does nothing to stop someone spoofing your domain. Set yourself a date to move to `quarantine`. **Reverse DNS and HELO that disagree.** A generic provider `PTR`, a `PTR` pointing to a name with no matching `A` record, or a `myhostname` left at `localhost` or the install-time name: any one of them is enough to make the receiver suspicious. **Forgotten IPv6.** If your VPS has an IPv6 address, Postfix will happily use it to reach Gmail, and that address then needs its own `PTR` and must be covered by SPF (the `a` mechanism includes the domain's `AAAA` records). Check with `dig -x` on the IPv6 address. Failing that, tell Postfix to prefer IPv4: ```bash theme={null} sudo postconf -e 'smtp_address_preference = ipv4' sudo systemctl reload postfix ``` **The `mail` host with no SPF.** Receivers may also check SPF against the name announced in `HELO`. A `TXT` record `"v=spf1 a -all"` on `mail.example.com` covers it. ## Going further * [Point a domain to a VPS](https://help.onetsolutions.net/vps/redirect-my-domain): the records the console writes for you. * [Reverse DNS (PTR)](https://help.onetsolutions.net/vps/reverse-dns): set and check your IP's PTR. * [Email ports](https://help.onetsolutions.net/vps/network#email-ports): the conditions for opening port 25. * [Enhanced security on a Linux VPS](/en/enhanced-vps-linux-security) for the layer underneath. Need port 25 opened, or a hand with the setup? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # Ubuntu 18.04 LTS Source: https://blog.onetsolutions.net/en/ubuntu-18-04-lts Ubuntu 18.04 LTS is now available for one-click install on our VPS. Ubuntu 18.04 LTS *Published on July 20, 2019* We have just released Ubuntu 18.04 LTS as a one-click install. This is the most polished release Ubuntu has ever shipped. To install it, just pick Ubuntu 18.04 LTS from your SoPanel. # Ubuntu 24.04 Noble Numbat: New Features and Improvements Source: https://blog.onetsolutions.net/en/ubuntu-24-04 Ubuntu 24.04 LTS 'Noble Numbat' is now available on our VPS — featuring GNOME 46, Linux 6.8, an updated installer, and more. Ubuntu 24.04 Noble Numbat: New Features and Improvements *Published on April 28, 2024* **Good news!** One-click installation of Ubuntu 24.04 is now available on our VPS. **Released on April 25, 2024**, the new version of Ubuntu — codenamed "Noble Numbat" — comes with a long list of promising new features and improvements. Whether you are a seasoned user or a curious newcomer, this major release brings plenty of pleasant surprises. **Among the major new features:** **A new GNOME 46 desktop:** offering a smoother and more intuitive interface, GNOME 46 brings many improved features such as a new application menu, better multitasking support, and redesigned system settings. **The Linux 6.8 kernel:** the new kernel brings improvements in performance, security, and hardware support. **Simplified installation:** the Ubuntu installer has been redesigned to deliver a more intuitive and faster experience, even for new users. **An updated software centre:** Ubuntu's software centre has a new look with a more modern, ergonomic interface. Finding and installing software is also easier. **Thunderbird as a Snap:** the Thunderbird email client is now available as a Snap, making it easier to install and update. **Netplan and Firmware Updater:** Netplan simplifies network management, while Firmware Updater makes it easier to update your system firmware. **Many other improvements:** Ubuntu 24.04 LTS also includes many other improvements such as better support for high-resolution displays, improved Bluetooth connectivity, and longer battery life on laptops. **In short, Ubuntu 24.04 LTS is a major release that brings many new features and improvements. Whether you are a home user, a professional, or a developer, this new version has something to offer.** **To learn more and discover everything new in Ubuntu 24.04 LTS, check out these resources:** * **Official Ubuntu site:** [https://ubuntu.com/](https://ubuntu.com/) * **Ubuntu 24.04 LTS release notes:** [https://discourse.ubuntu.com/c/release/38](https://discourse.ubuntu.com/c/release/38) * **What's new in GNOME 46:** [https://foundation.gnome.org/2024/03/20/introducing-gnome-46/](https://foundation.gnome.org/2024/03/20/introducing-gnome-46/) **Don't wait — switch to Ubuntu 24.04 LTS today!** # Ubuntu 26.04 LTS Resolute Raccoon Is Available on Our VPS Source: https://blog.onetsolutions.net/en/ubuntu-26-04 Linux 7.0, PHP 8.5, PostgreSQL 18 and support until 2031 — plus the breaking changes to check before you migrate a production server. Ubuntu 26.04 LTS Resolute Raccoon available on OnetSolutions VPS *Published on August 12, 2026* Ubuntu 26.04 LTS, codenamed **Resolute Raccoon**, was released on 23 April 2026. It is now available as a one-click install on our VPS. Five years of free security updates, through **April 2031**, extendable to ten with an Ubuntu Pro subscription. For a server you intend to leave alone, that is the number that matters. ## What you actually get The headline is Linux **7.0**, but on a server the interesting changes are lower down the stack. | Component | 24.04 LTS | 26.04 LTS | | - | - | - | | Linux kernel | 6.8 | **7.0** | | systemd | 255 | **259** | | OpenSSH | 9.6p1 | **10.2p1** | | Python | 3.12 | **3.14** | | PHP | 8.3 | **8.5** | | PostgreSQL | 16 | **18** | | MySQL | 8.0 | **8.4 LTS** | | Netplan | 1.0 | **1.2** | | Go | 1.22 | **1.25** | | Rust | 1.75 | **1.93** | | OpenJDK | 21 | **25** | PostgreSQL 18 is the upgrade worth planning around: its new I/O subsystem brings substantial gains on read-heavy workloads. PHP 8.5 matters if you host applications; check your framework's compatibility before you move. Post-quantum cryptography also lands as a default rather than an experiment. OpenSSL ships ML-KEM, ML-DSA and SLH-DSA, and OpenSSH 10.2 supports post-quantum key exchange. ## Read this before migrating This release removes things. Four changes can break a working server, and none of them announce themselves loudly. **cgroup v1 is gone.** systemd 259 drops support for the legacy and hybrid cgroup hierarchies. If you run an older container runtime, or you pinned `systemd.unified_cgroup_hierarchy=0` on a kernel command line years ago to fix something, that workaround is now a boot problem. **`sudo-rs` is the default sudo provider.** A memory-safe reimplementation, and a deliberate reduction in attack surface — but it does not cover every option of the original. Exotic `sudoers` rules deserve a test before you rely on them in production. **`apt-key` is removed.** APT 3.1 also switches from GnuTLS to OpenSSL. Any provisioning script still calling `apt-key add` will fail. Keys belong in `/etc/apt/keyrings/` with a `signed-by=` reference in the source entry. **DSA is removed from OpenSSH.** The algorithm has been deprecated for years, but if an old key or an embedded device still relies on it, the connection simply stops working. Two more worth noting: **chrony replaces systemd-timesyncd** as the default time daemon, and 26.04 is the **last release** to keep the systemd compatibility layer for System V init scripts. If you still ship one, this is your notice. ## Deploying a new server Pick Ubuntu 26.04 LTS when you order your instance, and it is installed and ready in a few minutes. Nothing else to do. Confirm what you are on once it boots: ```bash theme={null} # Distribution and codename lsb_release -a # Kernel — expect a 7.0 series uname -r ``` ## Upgrading an existing server The upgrade path is constrained. From **22.04 LTS or 25.04, you cannot jump straight to 26.04**: go through 24.04 LTS or 25.10 first. Attempting the shortcut wastes an evening. Check what your machine is actually offered: ```bash theme={null} # Full update of the current release first sudo apt update && sudo apt full-upgrade sudo reboot # What upgrade is available, if any do-release-upgrade -c ``` Then, once the upgrade is offered: ```bash theme={null} sudo do-release-upgrade ``` Take a [snapshot](https://help.onetsolutions.net/vps/snapshot) before you start. A distribution upgrade is the textbook case for one: if PostgreSQL does not come back up or a service refuses to start, you roll back in two minutes instead of debugging at midnight. Our step-by-step guide is in the [Ubuntu upgrade tutorial](https://help.onetsolutions.net/tutorials/how-to-upgrade-ubuntu-to-latest-version). A pattern worth resisting: upgrading a production server the same week an LTS lands. There is no prize for being early, and a fresh instance on 26.04 with your application redeployed onto it is almost always less painful than an in-place upgrade of a machine that has been accumulating history for four years. ## Should you move? If you are on **24.04 LTS**, there is no urgency — it is supported until 2029. Move when PostgreSQL 18 or PHP 8.5 buys you something concrete. If you are on **22.04 LTS**, standard support ends in April 2027. Start planning; the path runs through 24.04 anyway. If you are **deploying something new**, take 26.04 and buy yourself five years of quiet. Ready to try it? [Deploy an Ubuntu 26.04 LTS instance](https://console.onetsolutions.net/checkout/compute) from your client area. # Picking a VPS control panel in 2026: Easypanel, Dokploy, Cloudron, cPanel, Plesk, HestiaCP or YunoHost Source: https://blog.onetsolutions.net/en/vps-control-panel-comparison-2026 Web hosting, app platform or self-hosting suite: seven panels compared on licence, requirements and the kind of work each one is built for. *Published on September 24, 2026* Seven panels, three different jobs. Most bad picks are not bad panels. They are panels built for something else: cPanel to ship containers, Dokploy to host customer mailboxes. So start with the job. The rest follows from it. Comparison as of September 2026, based on each publisher's official documentation. Reference versions: Easypanel 2.36.0, Dokploy 0.30.7, Cloudron 10, cPanel & WHM 134 and later, Plesk Obsidian 18.0.81, HestiaCP 1.10.5, YunoHost 12.1 (13.0, built on Debian 13, is in beta). Licences and free tiers change quickly: check them with the publisher before you commit. ## Three families, not seven rivals | Family | Panels | What you manage | Basic unit | | - | - | - | - | | **Web hosting** | cPanel & WHM, Plesk, HestiaCP | Websites, email, databases, DNS | The domain or hosting account | | **App platform** | Easypanel, Dokploy | Containerised apps, databases, deployments from Git | The Docker service | | **Self-hosting suite** | Cloudron, YunoHost | Ready-made apps from a catalogue, users, email | The catalogue app | A web hosting panel thinks in accounts and domains. An app platform thinks in Git repositories and Docker images. A self-hosting suite thinks in apps installed for people: Nextcloud for the team, a webmail, a wiki. ## The comparison | Panel | Family | Licence | Free option | Built-in email | System installed at OnetSolutions | Minimum (vCPU / RAM / disk) | Install time | | - | - | - | - | - | - | - | - | | Easypanel | App platform | Paid plans per server | Up to 3 projects | No | Ubuntu 26.04 LTS | 1 / 2 GB / 30 GB | 3–5 min | | Dokploy | App platform | Apache 2.0 (except a proprietary directory) | Yes, open source | No | Ubuntu 26.04 LTS | 2 / 2 GB / 30 GB | 3–5 min | | Cloudron | Self-hosting suite | Source-available, subscription | 2 apps | Yes | Ubuntu 26.04 LTS | 2 / 2 GB / 30 GB | 15–25 min | | cPanel & WHM | Web hosting | Proprietary, priced by account count | No (trial period) | Yes | AlmaLinux 10 | 2 / 4 GB / 40 GB | 20–45 min | | Plesk | Web hosting | Proprietary, priced by domain count | No (trial period) | Yes | Ubuntu 26.04 LTS | 2 / 2 GB / 40 GB | 15–30 min | | HestiaCP | Web hosting | GPLv3 | Yes, no licence | Yes | Debian 13 | 1 / 2 GB / 20 GB | 10–20 min | | YunoHost | Self-hosting suite | AGPLv3 | Yes, no licence | Yes | Debian 12 | 1 / 2 GB / 20 GB | 10–20 min | The last four columns describe the automatic installation offered in the OnetSolutions console, when you order or reinstall a VPS. The minimums are those of that installation, not necessarily the publisher's. ## Pick by what you do ### You deploy your own applications: Easypanel or Dokploy Both build your apps from a Git repository or a Docker image, run them in containers next to their databases, and issue HTTPS certificates. * **Pick Dokploy** if you want an open source tool with no licence to pay for. It needs at least 2 vCPU. * **Pick Easypanel** if its template catalogue saves you time and 3 projects are enough, or if you accept a paid per-server plan beyond that. It runs on 1 vCPU. Neither hosts email. If your customers expect mailboxes, this is the wrong family. ### You host websites for customers: cPanel, Plesk or HestiaCP * **Pick cPanel & WHM** if your customers or your team already know cPanel, or if you resell hosting accounts. The licence is priced by account count: Solo (1), Admin (5), Pro (30), Premier (100 and more). It is also the heaviest: 4 GB of RAM minimum and up to 45 minutes to install. * **Pick Plesk** if you mostly run WordPress sites and prefer Ubuntu. Editions differ by domain count: Web Admin (10), Web Pro (30), Web Host (unlimited). Web Admin ships a reduced WP Toolkit, not the full one. * **Pick HestiaCP** if you want websites, email, databases and DNS without paying for a licence. It is lightweight, GPLv3, and built on Nginx and/or Apache with PHP-FPM, Exim and Dovecot, and BIND. The trade-off: no commercial publisher behind it, so support comes from the community. ### You self-host services for a team or a non-profit: Cloudron or YunoHost Both install apps from their catalogue, manage users and run a mail server. * **Pick YunoHost** if you want free software (AGPLv3) with no licence, backed by a volunteer community. It runs on 1 vCPU. * **Pick Cloudron** if you want a commercial product with app updates, per-app backups and single sign-on. The free plan is limited to **two apps**; beyond that, a subscription is required. ## Common pitfalls **Mixing up a panel and a One Click App.** A panel cannot be combined with a One Click App on the same VPS. If all you need is one WordPress or one n8n, a [One Click App](https://help.onetsolutions.net/one-click-apps/overview) may be enough. If you want to manage several sites or apps from one interface, take a panel. **Leaving the licence out of the budget.** cPanel, Plesk and Cloudron licences (beyond the free plan) are not included in the VPS: you buy them from the publisher once the trial or the free quota runs out. **Undersizing.** cPanel needs 4 GB of RAM at minimum. The others start at 2 GB, but a mail server with spam and virus filtering eats that margin fast. Size for the real workload, not for the installation alone. **Leaving the first account open.** Easypanel and Dokploy make the first account created the administrator. Until you create it, anyone who reaches `http://:3000` can do it instead of you. Create it as soon as the installation finishes. **Showing up to Cloudron without DNS.** Cloudron will not finish its setup without a domain. It needs `my.your-domain` and the wildcard `*.your-domain` pointed at the server. Check before you open the wizard: ```bash theme={null} # Both must return the VPS IP address dig +short my.example.com dig +short test.example.com ``` **Changing your mind later.** Moving from one panel to another means reinstalling the VPS, which erases all its data. Back up first, and plan to move your sites and apps yourself. ## Further reading * [Control panels overview](https://help.onetsolutions.net/control-panels/overview): ordering, reinstalling and tracking the installation * Per-panel guides: [Easypanel](https://help.onetsolutions.net/control-panels/easypanel), [Dokploy](https://help.onetsolutions.net/control-panels/dokploy), [Cloudron](https://help.onetsolutions.net/control-panels/cloudron), [cPanel & WHM](https://help.onetsolutions.net/control-panels/cpanel), [Plesk](https://help.onetsolutions.net/control-panels/plesk), [HestiaCP](https://help.onetsolutions.net/control-panels/hestiacp), [YunoHost](https://help.onetsolutions.net/control-panels/yunohost) * [VPS firewall](https://help.onetsolutions.net/vps/firewall): each panel has its own ports to open * [Enhanced VPS Linux security](/en/enhanced-vps-linux-security), for the layer under the panel To install one of these panels, [order a VPS from the console](https://console.onetsolutions.net/checkout/compute) and pick it at the installation step. # Control panels: pick one with your VPS Source: https://blog.onetsolutions.net/en/vps-control-panels Easypanel, Dokploy, Cloudron, cPanel & WHM, Plesk, HestiaCP or YunoHost: select a panel when you order, and it is installed by the time the server is ready. *Published on September 24, 2026* Putting a control panel on a VPS used to mean an SSH session, picking the right distribution, running an install script and watching the terminal. You no longer have to. You now choose the panel together with the server, in the console. It is installed automatically once the instance is created, on top of a compatible image. There is no installer for you to run. ## Seven panels to choose from | Panel | Image | Minimum (vCPU / RAM / disk) | Install time | Access port | In short | | - | - | - | - | - | - | | Easypanel | Ubuntu 26.04 LTS | 1 / 2 GB / 30 GB | 3–5 min | 3000 | Docker-based: apps, databases, sites, automatic HTTPS | | Dokploy | Ubuntu 26.04 LTS | 2 / 2 GB / 30 GB | 3–5 min | 3000 | Open source, Docker-based, deploys from Git, automatic HTTPS | | Cloudron | Ubuntu 26.04 LTS | 2 / 2 GB / 30 GB | 15–25 min | 443 | Self-hosting platform: installs and updates apps, built-in backups, email, user management | | cPanel & WHM | AlmaLinux 10 | 2 / 4 GB / 40 GB | 20–45 min | 2087 | cPanel licence required | | Plesk | Ubuntu 26.04 LTS | 2 / 2 GB / 40 GB | 15–30 min | 8443 | Plesk licence required | | HestiaCP | Debian 13 | 1 / 2 GB / 20 GB | 10–20 min | 8083 | Open source, lightweight: sites, email, databases, DNS, no licence | | YunoHost | Debian 12 | 1 / 2 GB / 20 GB | 10–20 min | 443 | Open source Debian-based self-hosting distribution: apps, email, users, backups, no licence | The panel sets the image: you do not pick the distribution, it follows. Install time comes on top of instance creation. cPanel & WHM and Plesk require a licence from their vendor. Easypanel and Cloudron have a free plan and paid plans: check their terms before you start. ## When you order, or when you reinstall You can pick a panel in two places: * **when ordering** a new instance; * **when reinstalling** an existing one. A reinstall erases the disk: back up first. A control panel cannot be combined with One Click Apps: an instance runs one or the other. ## First access Once the install is finished, the panel answers on the port listed in the table. With cPanel & WHM, Plesk and HestiaCP, your browser shows a self-signed certificate warning until a domain is configured. This is expected. On an instance running Cloudron, the **Domain** tab offers a dedicated DNS profile that writes the records this panel needs: see [Your domain on your VPS](/en/domain-linked-to-vps). ## Getting started Pick your panel when you [order a VPS](https://console.onetsolutions.net/checkout/compute). The documentation covers each panel, its requirements and first access: [overview](https://help.onetsolutions.net/control-panels/overview), [Easypanel](https://help.onetsolutions.net/control-panels/easypanel), [Dokploy](https://help.onetsolutions.net/control-panels/dokploy), [Cloudron](https://help.onetsolutions.net/control-panels/cloudron), [cPanel & WHM](https://help.onetsolutions.net/control-panels/cpanel), [Plesk](https://help.onetsolutions.net/control-panels/plesk), [HestiaCP](https://help.onetsolutions.net/control-panels/hestiacp), [YunoHost](https://help.onetsolutions.net/control-panels/yunohost). # Why Small Businesses Should Choose VPS Hosting Source: https://blog.onetsolutions.net/en/vps-hosting-for-small-businesses Why VPS hosting often is the right fit for small businesses — flexibility, performance, control, security, and expert support. Why Small Businesses Should Choose VPS Hosting *Published on February 4, 2024* Small businesses often have specific web hosting needs that a Virtual Private Server (VPS) can meet perfectly. In this article we cover the benefits of VPS hosting for small businesses and why it can be the best option for their online presence. ### 1. Flexibility and scalability One of the main benefits of VPS hosting for small businesses is flexibility and scalability. With a VPS, you can easily adjust resources to match your fluctuating needs. Whether you need more processing power, memory, or storage, you can easily upgrade your VPS plan to meet your growing requirements. ### 2. Improved performance Compared to shared hosting — where resources are shared across many users — a VPS delivers more reliable and consistent performance. You get dedicated resources that ensure fast page loads for your website, which is essential for a good user experience and better search engine rankings. ### 3. Full control With a VPS, you have full control over your hosting environment. You can install and configure custom software, change server settings to match your needs, and manage your own security. That level of control lets you tailor your hosting precisely to your unique business requirements. ### 4. Improved security Security is a top concern for any online business, and small businesses are no exception. VPS servers offer stronger security than shared hosting because each VPS is isolated from the others, reducing the risk of compromise from malicious neighbours. You can also put in place custom security measures to protect your sensitive data. ### 5. Expert technical support Most VPS hosting providers offer expert technical support to help when issues come up. Whether it is configuration questions, performance issues, or security concerns, you can rely on experienced professionals to resolve issues quickly and effectively. ### Conclusion For small businesses, VPS hosting provides a reliable, flexible, and secure way to host their website and online applications. With improved performance, full control, stronger security, and expert support, a VPS is a smart choice for businesses looking to grow their online presence efficiently and cost-effectively. If you are a small business looking for a reliable and scalable web hosting solution, a VPS could be exactly what you need to succeed online. # An Upgrade for Our VPS Plans Source: https://blog.onetsolutions.net/en/vps-plan-upgrade Our refreshed VPS pricing is live: more NVMe storage, harmonised SSD storage, and updated options for backups, snapshots and managed services. An Upgrade for Our VPS Plans *Published on October 2, 2021* After several months of work, the new pricing for our [VPS plans](https://onetsolutions.net/serveur-vps) is now live. It includes a major boost in NVMe storage, harmonised SSD storage, and changes to our optional add-ons (backup, snapshot, managed service, supported operating systems). ### A toolkit to keep your data safe * Automated backup: €4.99 * On-demand snapshot: €2.99 ### NVMe storage available to everyone Here is a summary of the changes to our plans: ### Loyalty rewarded Multi-month payment comes with significant discounts: * 1 year: 20% * 2 years: 30% Discover our plans here: [https://onetsolutions.net/serveur-vps](https://onetsolutions.net/serveur-vps) # Windows Server 2019 Source: https://blog.onetsolutions.net/en/windows-server-2019 Windows Server 2019 is now available for one-click install on our VPS. Windows Server 2019 *Published on July 20, 2019* We have just released Windows Server 2019 as a one-click install.\ This is the most polished release Microsoft has ever shipped. To install it, just pick Windows Server 2019 from your SoPanel. # Windows Server 2025 Now Available Source: https://blog.onetsolutions.net/en/windows-server-2025 Deploy your instances on Windows Server 2025 with the licence included in the price — connect via RDP and get to work in minutes. Windows Server 2025 now available on OnetSolutions VPS *Published on July 14, 2026* Linux or Windows? Both! You can now deploy your instances on Windows Server 2025, the latest version of Microsoft's server operating system. ## Licence included No separate licence line on your invoice: Windows Server 2025 is offered with the licence included in the price of your VPS. On most competing offers, the Windows licence is a monthly add-on that quickly inflates the bill — here it is simply part of the plan. ## Ready in minutes, RDP access Select Windows Server 2025 when ordering your instance, wait a few minutes, and connect through Remote Desktop (RDP). No ISO to upload, no activation to handle — the server is ready to work. ## Which plan should you choose? For a comfortable Windows experience, we recommend plans with 8 GB of RAM or more. The 16 GB plans absorb heavier workloads such as business applications, databases or a busy remote desktop. ## Switch whenever you want As with all our systems, there is no commitment: you can reinstall your instance under Debian, Ubuntu, AlmaLinux, or Rocky Linux at any time from the console. Ready to try it? [Deploy a Windows Server 2025 instance](https://console.onetsolutions.net/checkout/compute) from your client area. # wp2shell (CVE-2026-63030): Unauthenticated Remote Code Execution in WordPress Core Source: https://blog.onetsolutions.net/en/wp2shell-cve-2026-63030 A batch-API routing flaw chained with an SQL injection gives full site takeover without credentials. Patched in 6.9.5 and 7.0.2, and exploited in the wild. *Published on August 8, 2026* **CVE-2026-63030 — "wp2shell", CVSS 9.8.** No account, no password, no user interaction: a single request chain takes over the site. Exploitation is confirmed in the wild and the flaw is in CISA's KEV catalog. If you run WordPress 6.9.x or 7.0.x, update before you read the rest. ## What is affected This is a core vulnerability, not a plugin one. No amount of plugin hygiene protects you. | Branch | Vulnerable | Patched | | - | - | - | | WordPress 6.9 | 6.9.0 → 6.9.4 | **6.9.5** | | WordPress 7.0 | 7.0.0 → 7.0.1 | **7.0.2** | | WordPress 7.1 | Beta 1 and earlier | Beta 2 | | WordPress 6.8 | 6.8.0 → 6.8.5, for CVE-2026-60137 only | 6.8.6 | Sites on 6.8.x are not exposed to the full chain — the batch-API flaw was introduced in 6.9 — but they still need 6.8.6 for the SQL injection half. ## How the chain works Two flaws, neither of which is enough on its own. **CVE-2026-63030** is a logic bug in the REST API batch processor, at `/wp-json/batch/v1`. Validation and execution run in two separate loops. When `wp_parse_url()` fails on a sub-request path, the error is appended to the validation array but not to the matches array. The two arrays fall out of alignment, and from that point on every subsequent sub-request is dispatched under the wrong handler. That misalignment is the whole trick: a request gets executed by a handler that never validated its parameters. **CVE-2026-60137** is an SQL injection in the `author__not_in` parameter of `WP_Query`, scored 5.9 on its own — the kind of finding that would normally sit in a backlog. Chained, the routing confusion delivers unvalidated parameters into the injectable query. The published path goes from there to creating an administrator account, and from an administrator account to code execution through the plugin installer. Full site takeover, no credentials at any step. This is a good illustration of why a medium-severity finding is not a low-priority one. CVE-2026-60137 alone is a 5.9. Given a routing bug to pair with, it becomes half of a 9.8. ## Timeline, and why it matters * **17 July 2026** — public disclosure via a GitHub Security Advisory. Public proof-of-concept exploits appeared on GitHub within hours. * **21 July 2026** — CISA adds both CVEs to the Known Exploited Vulnerabilities catalog. * **22 July 2026** — full technical write-up of the chain published. A KEV listing means exploitation has been observed against real systems, not merely predicted. The gap between disclosure and working public exploit was measured in hours, which leaves no room for a "we will patch next sprint" posture. ## Updating WordPress.org pushed forced automatic updates to affected installations that had auto-updates enabled. Do not assume this covers you — sites with auto-updates disabled, sites under version control, and sites where the core files are not writable were not updated. Check what you are actually running: ```bash theme={null} # From the site root, with WP-CLI wp core version # Without WP-CLI, the version lives in this file grep "wp_version =" wp-includes/version.php ``` Then update: ```bash theme={null} # Update core to the latest release of your branch wp core update # Database schema migration, required after a core update wp core update-db # Confirm wp core version ``` If you manage your site through cPanel, WordPress Toolkit and [Softaculous](https://help.onetsolutions.net/web-hosting/softaculous) both expose a one-click core update and a per-site version list — the fastest way to audit several sites at once. Take a backup before updating, not after. If the update goes badly you want a rollback point; if you turn out to have been compromised, you want a copy of the evidence. ## Checking whether you were hit Patching closes the door. It does nothing about anyone already inside. Three checks, in order of usefulness: **Unexpected administrator accounts.** The published chain creates one. Look at every account with elevated rights and the date it was created. ```bash theme={null} wp user list --role=administrator --fields=ID,user_login,user_email,user_registered ``` **Requests to the batch endpoint.** The endpoint has legitimate uses, so volume and source matter more than presence. ```bash theme={null} # Adjust the path to your access log grep "batch/v1" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head ``` **Files that changed recently.** A web shell dropped through the plugin installer lands in `wp-content`. ```bash theme={null} # PHP files modified in the last 30 days, most recent first find wp-content -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %p\n" | sort -r | head -40 ``` Compare that list against your own deployments. A PHP file in `wp-content/uploads` is essentially never legitimate. If any of these turn something up, treat the site as compromised: restore from a backup predating the first suspicious event, then update, then rotate every password and API key. Cleaning a live compromised site file by file rarely ends well — see our [checklist for hardening WordPress after this incident](/en/secure-wordpress-after-wp2shell). ## The wider point WordPress core vulnerabilities of this severity are rare — the attack surface that usually gets exploited is plugins and themes. That rarity cuts both ways: because core is trusted, core updates are more often postponed on "stable" production sites, and a site that has not been touched in a year is exactly the one still sitting on 6.9.2. Automatic updates for minor core releases are on by default for a reason. If you disabled them, this is the incident that should make you reconsider. Questions about a site hosted with us? [Our team is available](https://help.onetsolutions.net/console/support) from your client area. # xz-utils Backdoor (CVE-2024-3094): A Textbook Supply-Chain Attack Source: https://blog.onetsolutions.net/en/xz-backdoor-cve-2024-3094 A deliberate backdoor planted in xz-utils 5.6.0 and 5.6.1 targeted OpenSSH via systemd. Caught early, narrow blast radius — but the lesson is huge. *Published on April 2, 2024* **CVE-2024-3094.** A backdoor was deliberately planted in versions **5.6.0** and **5.6.1** of the `xz-utils` library. Caught on March 29, 2024 by a curious Postgres developer investigating unusual SSH connection times, the attack was stopped before it reached stable distributions. But it could have made it — and that is the real story. ## What happened Over the course of two years, a contributor under the pseudonym **Jia Tan** earned the trust of the `xz-utils` community, eventually becoming co-maintainer. With that role, they progressively injected, across several scattered commits, an obfuscated payload into the `liblzma` library. At build time, the payload: 1. Detects that it is being compiled in a context that will later be loaded by `sshd` via `systemd` (distributions that patch `sshd` to depend on `libsystemd`, which itself depends on `liblzma`). 2. Hooks specific internal `sshd` functions at startup. 3. Lets anyone in possession of a specific key bypass SSH authentication **as any user, with no log trace**. In other words: universal root access on tens of millions of servers, through a backdoor that classical security tooling would not have flagged. ## Why this did not become a global disaster Andres Freund, a Postgres maintainer at Microsoft, was debugging suspicious 500ms SSH connection times. Following the trail, he eventually surfaced the payload — and reported to `oss-security` on March 29, 2024. At that point, versions 5.6.0 and 5.6.1 only shipped in: * **Fedora 41 and Rawhide** * **Debian testing/unstable/experimental** * **openSUSE Tumbleweed**, **openSUSE MicroOS** * **Arch Linux** * A few *bleeding edge* macOS channels via Homebrew No stable production distribution shipped those versions. The actual compromise perimeter was tiny. ## Are you affected? Check your installed `xz` version: ```bash theme={null} xz --version ``` If the output shows **5.6.0** or **5.6.1**, you are potentially exposed. ```bash theme={null} # Debian/Ubuntu dpkg -l xz-utils liblzma5 # Fedora/RHEL/AlmaLinux/Rocky rpm -qa | grep -i xz # Arch pacman -Q xz ``` ## What to do ### If you are on a 5.6.x version Downgrade to 5.4.x (the last clean release) immediately. Every affected distribution has shipped fixed packages by now. On Arch: ```bash theme={null} sudo pacman -Syyuu # full upgrade ``` On Debian unstable/testing: ```bash theme={null} sudo apt update && sudo apt install --reinstall xz-utils liblzma5 ``` ### If you are on a stable distribution You are not affected. 5.6.0/5.6.1 never reached Debian stable, Ubuntu LTS, RHEL stable, etc. ### Either way Use the episode to ask the broader question: **which packages do you build from source or install from unofficial repos?** The xz-utils attack exposed how fragile a model can be where a single maintainer of a critical library can compromise the planet. That calls for: * Strict reduction of internally-built dependencies. * Use of signed, auditable mirrors. * Tighter review of critical transitive dependencies (crypto libs, compression libs, drivers, etc.). ## Takeaways xz-utils is not a classical "vulnerability": it is a **supply-chain attack** on open-source software, with long-running social engineering (two years of work) and a sophisticated technical payload. Practical lesson: update to a clean version. Strategic lesson: trust in open-source code is not just "it's public". Audit what you ship. For questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net). # YunoHost: Easy and Secure Self-Hosting Source: https://blog.onetsolutions.net/en/yunohost-easy-and-secure-self-hosting YunoHost on Debian 11 is now available as a one-click install on our VPS — making it simple to self-host your online services. YunoHost: Easy and Secure Self-Hosting *Published on May 13, 2023* At OnetSolutions, we are happy to announce that YunoHost is now available on our VPS as a one-click install. It is a powerful combo for simplifying self-hosting and managing your online services. Debian 11, the latest release of one of the most stable and reliable Linux operating systems, paired with YunoHost — an all-in-one open-source platform — gives you a complete solution to set up and manage your own server. In this article we cover YunoHost's key features and explain how this addition reinforces our commitment to our customers. **Debian 11 — Stability, security and flexibility** Debian is known for stability, reliability and security. The latest release, Debian 11, combines those qualities with significant improvements in performance and features. Whether you are a developer, sysadmin or end user, Debian 11 delivers a smooth experience and a solid foundation for your applications and services. Debian benefits from an active and engaged community that ensures regular updates and long-term support. You can count on Debian 11 to stay current on security and features, providing a reliable and protected environment for your data. **YunoHost — Simplify your self-hosting** YunoHost is an open-source platform designed to make self-hosting online services easy. With YunoHost, you can install and manage web applications such as blogs, forums, collaboration tools, file managers and much more. It offers a user-friendly interface so you can manage your services without deep technical knowledge. YunoHost provides a catalogue of pre-configured applications for quick and simple installation. It also automates common tasks such as backups, software updates, and user management — saving you time and letting you focus on other parts of your project. **YunoHost + Debian 11** By choosing Debian 11 + YunoHost at OnetSolutions, you get a performant and stable Linux operating system combined with a friendly self-hosting platform. Our state-of-the-art infrastructure ensures optimal performance for your online services and a smooth experience for you and your users.