• The APS Catalog has been deprecated and removed from all Plesk Obsidian versions.
    Applications already installed from the APS Catalog will continue working. However, Plesk will no longer provide support for APS applications.
  • Please be aware: with the Plesk Obsidian 18.0.78 release, the support for the ngx_pagespeed.so module will be deprecated and removed from the sw-nginx package.

Issue [BUG] sw-nginx 1.30.1 (CVE-2026-42945 patch) crashes with SIGABRT on AlmaLinux 9.7 + OpenSSL 3.5.1

T

thilo72

New Pleskian
Server operating system version
AlmaLinux 9.7
Plesk version and microupdate number
18.0.77 #2
Hi,

I'd like to report a reproducible crash of sw-nginx 1.30.1 that was introduced as part of the CVE-2026-42945 security patch rollout via Plesk.

Environment at time of crash:
- Plesk Obsidian 18.0.77.2
- AlmaLinux 9.7
- OpenSSL 3.5.1 (installed via dnf automatic updates)
- sw-nginx 1.30.1-2.redhat.9+p18.0.77.2+t260415.1740

Current state:
- Upgraded to Plesk 18.0.78.1, AlmaLinux 9.8, OpenSSL 3.5.5
- sw-nginx still pinned to 1.28.3 (see below)
- Available in repo: sw-nginx 1.30.1-2.redhat.9+p18.0.78.1+t260514.1639 (new build, untested)

What happened:

After dnf automatic updated OpenSSL to 3.5.1 on AlmaLinux 9.7, Plesk pushed sw-nginx 1.30.1 as a security update (CVE-2026-42945). Within minutes of sw-nginx 1.30.1 starting, all nginx worker processes crashed repeatedly with SIGABRT and heap corruption errors. The server returned 525 errors via Cloudflare (connection timed out at origin). Downgrading to sw-nginx 1.28.3 immediately resolved the issue.

Symptoms:
- nginx worker processes crash with SIGABRT
- journalctl shows heap corruption in sw-nginx worker
- All domains return 525 (Cloudflare) / connection refused
- sw-nginx master process keeps trying to restart workers, which immediately crash again

Current workaround:
- sw-nginx pinned to 1.28.3 via excludepkgs=sw-nginx* in dnf.conf
- Additional lock via Plesk UI to prevent pum from upgrading (pum ignores dnf.conf excludes)
- RPM backup stored at /usr/local/sbin/ for emergency rollback

The problem this creates:

Staying on sw-nginx 1.28.3 means remaining vulnerable to CVE-2026-42945. This is not acceptable long-term. However, upgrading to 1.30.1 crashes the server. I am stuck between a security vulnerability and a stability issue.

A new build of sw-nginx 1.30.1 is now available for Plesk 18.0.78.1 (built 2026-05-14), but I cannot safely test it on a production server. I do not know whether the new build resolves the OpenSSL 3.5 incompatibility.

Questions:
1. Is the sw-nginx 1.30.1 build shipped with Plesk 18.0.78.1 known to be compatible with OpenSSL 3.5.x on AlmaLinux 9?
2. If not, is a fixed build in progress?
3. Is there a safe way to verify the new build before fully committing to the upgrade?

Has anyone else hit this combination? Any input appreciated.
 
Kaspar said:
For what it's worth, I am currently running nginx 1.30.2 (from Plesk 18.0.78#2) with OpenSSL 3.5.5 on AlmaLinux 9.8 on production servers without any issues.
Click to expand...
Thank you. Reassuring. I guess you meant 1.30.1.2 at least I don't see a newer version. Trying it out now.
 
thilo72 said:
Thank you. Reassuring. I guess you meant 1.30.1.2 at least I don't see a newer version. Trying it out now.
Click to expand...
No, nginx got updated to 1.30.2 (after yet another vulnerability), this update gets distributed with the Plesk 18.0.78 #2 (and 18.0.77 #4) updates. See Plesk change log for released updates. It might be worth updating your Plesk installation to the latest update (18.0.78 #2 or 18.0.77 #4) and upgrade Alma to 9.8 afterwards, so you to run the latest available openSSL version.
 
Last edited:
Following up on this thread with a new data point that might help others who upgraded to Plesk 18.0.78.3.

Environment:
- AlmaLinux 9.8
- Plesk 18.0.78.3
- sw-nginx 1.30.2-2.redhat.9+p18.0.78.2+t260526.1033
- OpenSSL 3.5.5-2.el9_8.x86_64

Symptom:
After the Plesk update ran overnight (sw-nginx installed at 03:30), worker crashes started within 5 minutes. Same SIGABRT signature as reported in this thread:

#3 abort
#4 __libc_message.cold
#5 malloc_printerr
#6 _int_free
#7 free
#8 ossl_statem_server_post_process_message (libssl.so.3)
#9 state_machine (libssl.so.3)
#10 ngx_ssl_handshake.part.0
#11 ngx_http_ssl_handshake

751 coredumps in the first 9 hours (roughly 4-5 per minute), all SIGABRT, all in the same stack trace location. Workers were being respawned fast enough that most traffic still went through, but check_https() failed periodically when too many workers crashed simultaneously.

Root cause candidate - HTTP/3 auto-enabled by Plesk:

Plesk 18.0.78.3 ships sw-nginx with --with-http_v3_module compiled in and automatically adds listen 443 quic directives to all SSL vhosts during the update. In our case that was 60 vhosts.

The crashes appear to be triggered by the QUIC SSL context initialization interacting with the regular TLS path. The crash itself occurs in HTTP/1.x TLS handshake code (ngx_http_ssl_handshake), not in the QUIC path - which is why it's not obvious from the stack trace.

Workaround - confirmed working:

Disable HTTP/3 in Plesk:
Tools & Settings -> Apache & nginx Settings -> nginx Settings -> HTTP/3 support -> uncheck -> Apply

Zero crashes immediately after disabling. Server has been stable since.

Note for Cloudflare users: Disabling HTTP/3 at the origin has no user-visible impact if you are behind Cloudflare - Cloudflare continues to advertise alt-svc: h3=":443" to browsers and handles HTTP/3 at the edge independently. Confirmed on Free plan.

This is a correlation-based diagnosis, not a code-level analysis - but the timing (crashes started 5 minutes post-install, stopped immediately on disabling HTTP/3) is about as clean as it gets.

Call to action for Plesk:

The workaround (disabling HTTP/3) is not a fix. The underlying issue is that Plesk 18.0.78.3 automatically enables HTTP/3 on all SSL vhosts during the sw-nginx upgrade without apparently having verified that the QUIC SSL context initialization is stable on AlmaLinux 9.8 + OpenSSL 3.5.5. The result is a silent production outage for any user who upgrades and has more than a handful of SSL vhosts.

Two things need to happen on Plesk's side:

1. Identify and fix the actual bug in sw-nginx 1.30.2.2's QUIC implementation that causes heap corruption in the regular TLS path.
2. Reconsider the upgrade behavior - auto-enabling HTTP/3 across all vhosts without a stability gate is what turned a latent bug into an immediate outage for upgraded servers.

Happy to provide additional coredumpctl output or a full nginx -T dump if that helps narrow it down.

PS: My apologies if I got anything wrong here. I'm happy to receive any hints for better understanding.
 
Bitpalast said:
It has not here on Alma 8 updates from 18.0.77 to 18.0.78. But maybe it does so on Alma 9???
Click to expand...
Good point - and fair to challenge us on that. Honestly, we are not 100% sure that Plesk 18.0.78.3 activated HTTP/3. We did not explicitly verify whether it was already active before the update. What we know for certain is that listen 443 quic was present on all vhosts during the crash, and disabling HTTP/3 in Plesk stopped it immediately.
Your AL8 observation actually points to a more interesting root cause: the difference is probably not how Plesk handles HTTP/3 activation, but the OpenSSL version. AL9 runs OpenSSL 3.5.x, AL8 runs an older version. The crash was in ossl_statem_server_post_process_message - an OpenSSL SSL state machine function. That looks like a compatibility issue between the QUIC implementation in sw-nginx 1.30.2.2 and OpenSSL 3.5.x specifically. On AL8 with an older OpenSSL version, that problem would probably not surface.
So AL9 vs. AL8 is probably just a proxy for OpenSSL 3.5.x vs. older. Whether Plesk 18.0.78.3 activated HTTP/3 or it was already on before - we cannot say with confidence.
 
Kaspar said:
I am pretty sure it didn't. On none of my Alma 9 servers HTTP/3 got enabled after upgrading to .78. HTTP/3 is still considered experimental by Plesk and as such needs to be enabled explicitly via Tools & Settings > Apache & Nginx Settings. Even on fresh installations.
Click to expand...
That makes a lot of sense - thank you for the clarification. We must have had HTTP/3 enabled before the upgrade at some earlier point, probably without realizing it was still considered experimental.
So the actual picture is: HTTP/3 was already active on our server, worked fine until sw-nginx 1.30.2.2 introduced a crash with QUIC + OpenSSL 3.5.x on AlmaLinux 9. The upgrade did not activate HTTP/3 - it just exposed a bug in the new nginx build with an already-active experimental feature.
We are keeping HTTP/3 disabled now.
Thanks again for pushing back on that.
 
You must log in or register to reply here.

Similar threads

R
Resolved CVE-2026-42945 Nginx Rift and older Wordpress Toolkit heads up
Replies
14
Views
3K
rhall
R
Back
Top