CVE-2026-98432: Critical Linux Kernel Use-After-Free in IPv4 TCP — What It Is and How to Fix It

Futuristic server room network diagram showing a red failure spreading through blue system connections

CVE-2026-98432: Critical Linux Kernel Use-After-Free in IPv4 TCP — What It Is and How to Fix It

A critical vulnerability in the Linux kernel (CVE-2026-98432) has drawn significant attention. Rated 9.8 (Critical) by the Linux kernel CVE team and marked High priority by Ubuntu, it involves a use-after-free race condition in IPv4 TCP option handling.

As of late October 2026, fixed packages are available on several distributions including Debian, Oracle Linux, parts of Amazon Linux, openSUSE Leap 16.0, and SUSE Linux Micro 6.2. Ubuntu still lists supported releases as vulnerable with fixes in progress, while Red Hat has deferred its fix. A research demonstration (involving Anthropic’s Claude) reportedly produced a laboratory remote-root exploit under specific conditions, underscoring the need for prompt action once patches arrive.

What Is CVE-2026-98432?

The bug lives in the IPv4 TCP handshake code. When the kernel creates a new child socket from a request socket (tcp_v4_syn_recv_sock()), it transfers ownership of the IP options (ireq->ireq_opt → newinet->inet_opt) without copying them.

A concurrent CPU can process a retransmitted SYN for the same request socket and build a SYNACK (tcp_v4_send_synack() → ip_options_build()). Because the options are freed with a plain kfree() (no RCU grace period) when the child socket is destroyed, this creates a classic use-after-free. A related path exists with TCP request-socket migration (net.ipv4.tcp_migrate_req=1 or certain BPF programs).

IPv6 is largely unaffected by the primary issue (options are duplicated), though a similar migration problem exists for CALIPSO and is addressed separately.

The flaw has been present since roughly Linux 4.4. Upstream fixed it by switching to kfree_rcu() in the relevant destructors (commit e3f33b0a1d89...). Stable kernels that include the fix include 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and mainline 7.3+.

Impact and Exploitability

  • Remote, unauthenticated network attack surface (TCP connections).
  • Potential outcomes: kernel crash / denial of service, memory corruption, or (in advanced cases) privilege escalation to root.
  • Winning the race is non-trivial, which is why some vendors score it lower (e.g., SUSE and Oracle 8.1, Red Hat ~5.9–8.1, Amazon 7.0). Ubuntu and the kernel CNA use the 9.8 score.
  • No confirmed widespread in-the-wild exploitation has been reported as of this writing, and it is not listed in CISA’s KEV catalog. However, a public research demonstration of a zero-click remote-root chain (particularly effective against multipath TCP listeners) raises the urgency.

Any system accepting TCP connections on a vulnerable kernel is potentially exposed—servers, cloud instances, containers sharing the host kernel, etc.

Current Status (as of 29 October 2026)

DistributionStatusNotes / Fixed Version
Ubuntu 22.04 / 24.04 / 26.04 / 26.10Vulnerable – fix in progressTarget versions exist but not yet released
Ubuntu 16.04 / 18.04 / 20.04VulnerableNo fix date announced
Debian 12 (bookworm) / 13 (trixie)Fixed6.1.190-1 / 6.12.113-1
Oracle Linux (UEK)FixedMultiple ELSA advisories
Amazon Linux 2023 (some kernels)Partially fixedkernel 6.18 and 6.12 fixed; others pending
openSUSE Leap 16.0Fixedkernel 6.12.0-160000.40.1 or later
SUSE Linux Micro 6.2Fixedkernel 6.12.0-160000.40.1 or later
SLES 15 SP4–SP6 LTSS / SLES 16.0Fixed or in progressSee SUSE advisories (e.g. SUSE-SU-2026:24386-1)
RHEL 8/9/10 + OpenShiftFix deferredNo released packages yet

Always check the official trackers (Ubuntu CVE page, SUSE CVE page, etc.) for the latest package status, as this changes quickly.

How to Check If You Are Affected

  1. Identify your running kernel: uname -r
  2. On Ubuntu: dpkg -l | grep linux-imageThen match against https://ubuntu.com/security/CVE-2026-98432.
  3. On openSUSE / SUSE: rpm -q kernel-default # or zypper se -s kernel-defaultCompare against the fixed version (e.g. 6.12.0-160000.40.1+).
  4. Monitor for available updates on your distribution.

Steps to Fix the Vulnerability

Primary fix: Install the patched kernel and reboot.

On Ubuntu (once packages are published)

sudo apt update
sudo apt full-upgrade
sudo reboot

On Debian

sudo apt update
sudo apt full-upgrade
sudo reboot

On openSUSE Leap / SUSE Linux Enterprise / SUSE Linux Micro

sudo zypper refresh
sudo zypper update
# or more specifically:
sudo zypper in -t patch openSUSE-...   # follow the exact patch name from the advisory
# or
sudo zypper up kernel-default
sudo reboot

For openSUSE Leap 16.0 and SUSE Linux Micro 6.2 the fixed kernel is 6.12.0-160000.40.1 (or later). After updating, confirm with uname -r.

On RHEL / AlmaLinux / Rocky / Oracle (when available)

sudo dnf update kernel
sudo reboot

Important: The vulnerability is fixed only after the system is running the patched kernel. Simply installing the package is not enough—reboot is mandatory.

Temporary Mitigations (While Waiting for Patches)

These reduce attack surface but do not fully eliminate the primary race:

  • Disable TCP request-socket migration: sudo sysctl -w net.ipv4.tcp_migrate_req=0Make it persistent by adding the line to /etc/sysctl.d/99-tcp-migrate.conf (or similar) and running sysctl --system.
  • Limit exposure of TCP services to untrusted networks (firewall rules, security groups, reverse proxies).
  • Prefer IPv6-only listeners where feasible (the primary path is IPv4-specific).
  • Avoid enabling multipath TCP (MPTCP) on publicly reachable services if not required.

These are stop-gaps only. The real solution is the kernel update.

Best Practices Going Forward

  • Subscribe to your distribution’s security notices (Ubuntu USN, SUSE Security Advisories, etc.).
  • Enable automatic security updates where appropriate, but treat kernel updates carefully (test first in non-production).
  • Maintain an inventory of kernel versions across your fleet (especially cloud instances and containers).
  • For high-security environments, consider live-patching solutions once they support this CVE, though a full reboot remains the cleanest approach for kernel fixes of this type.

Conclusion

CVE-2026-98432 is a serious race-condition use-after-free in a core networking path. While reliable remote exploitation is non-trivial, the combination of a 9.8 CVSS score, network reachability without authentication, and demonstrated research exploits makes it high priority.

Monitor the official trackers closely. As soon as fixed kernel packages appear for your release (already available for openSUSE Leap 16.0, SUSE Linux Micro 6.2, Debian, and Oracle), install them and reboot. Until then, apply the temporary mitigations and restrict network exposure.

Stay patched, stay safe.

PHP2Shell: Critical PHP Remote Code Execution Vulnerabilities Require Immediate Action

phpshell

PHP2Shell: Critical PHP Remote Code Execution Vulnerabilities Require Immediate Action

phpshell

The PHP community has released emergency security updates to address two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively being referred to as PHP2Shell. Both vulnerabilities can allow an unauthenticated attacker to execute code on affected web servers through specially crafted HTTP requests. PHP has rated both vulnerabilities as 9.2 (Critical) and administrators should patch immediately. [almalinux.org], [almalinux.org]

The vulnerabilities affect multiple PHP versions and deployment methods, including PHP-FPM, Apache mod_php, CGI, LiteSpeed, and FrankenPHP installations. PHP released fixed versions on October 21, 2026, with updates available in:

  • PHP 8.2.35
  • PHP 8.3.36
  • PHP 8.4.27
  • PHP 8.5.12

[almalinux.org], [phpvulnera…lities.app]

ViciBox 11 and ViciBox 12

The ViciDial team has already published fixes for supported ViciBox releases.

ViciBox 11

Documentation:

Update commands:

zypper ref
zypper dup --from openSUSE-Leap-15.5-ViciDial-ViciBox --allow-vendor-change
systemctl restart apache2

After updating, verify PHP:

php -v

You should see:

PHP 7.4.34-dev

ViciBox 12

Documentation:

Update commands:

zypper ar https://download.opensuse.org/repositories/devel:/languages:/php:/php82/openSUSE_Leap_15.6/devel:languages:php:php82.repo
zypper mr -f devel_languages_php_php82
zypper --gpg-auto-import-keys ref
zypper dup --from devel_languages_php_php82 --allow-vendor-change
systemctl restart apache2

After updating, verify PHP:

php -v

You should see:

PHP 8.2.35 or later.

Important Note for ViciBox 11 Users

The ViciDial team has indicated that it is becoming increasingly difficult to maintain and build packages for the aging ViciBox 11 platform. Administrators still running ViciBox 11 or older should begin planning an upgrade path, as older openSUSE repositories may eventually be removed from public mirrors.


AlmaLinux Fix

AlmaLinux has released patched PHP packages for all supported PHP streams across AlmaLinux 8, 9, and 10. The AlmaLinux project confirmed that patched packages are now available in the production repositories. [almalinux.org]

To update:

sudo dnf clean metadata
sudo dnf upgrade 'php*'

Restart PHP-FPM:

sudo systemctl restart php-fpm

If you are using Apache with mod_php:

sudo systemctl restart httpd

Verify the installed version:

php -v

For systems running PHP 8.2, the patched version should be:

PHP 8.2.35

or newer. AlmaLinux has also backported protections for some older, end-of-life streams where possible. [almalinux.org], [computingf…rgeeks.com]


Rocky Linux Fix

Rocky Linux administrators can patch affected systems using the standard AppStream update process. Updated packages have been synchronized from Red Hat’s security advisories for supported PHP streams. [computingf…rgeeks.com]

Update PHP:

sudo dnf upgrade 'php*'

Restart services:

sudo systemctl restart php-fpm
sudo systemctl restart httpd

Verify:

php -v

Supported streams should be updated to patched package releases, including PHP 8.2.35 and PHP 8.3.36 where applicable. [computingf…rgeeks.com], [php2shell.app]


Special Notice for VICIdial Servers Running PHP 7.4

Many older VICIdial deployments on AlmaLinux 8, Rocky Linux 8, and ViciBox 11 continue to use PHP 7.4. While the upstream PHP project no longer maintains the 7.4 branch, several distributions have backported security fixes to their packaged versions. The PHP2Shell vulnerabilities have been patched in supported vendor repositories even though the version number may still report as PHP 7.4.x. Administrators should not assume they are protected simply because they are running PHP 7.4 and should verify that all available operating system updates have been installed. [computingf…rgeeks.com], [php2shell.app]

AlmaLinux PHP 7.4

Update all PHP packages:

sudo dnf clean all
sudo dnf upgrade 'php*'
sudo systemctl restart httpd

Verify installed packages:

rpm -q php-common
php -v

AlmaLinux has released patched packages for PHP 7.4 in its repositories, including backported fixes for the PHP2Shell vulnerabilities. [computingf…rgeeks.com], [almalinux.org]

Rocky Linux PHP 7.4

Update all PHP packages:

sudo dnf clean all
sudo dnf upgrade 'php*'
sudo systemctl restart httpd

Verify package versions:

rpm -q php-common
php -v

Rocky Linux has synchronized the corresponding security updates from Red Hat for supported PHP 7.4 streams. Because Red Hat backports security fixes, the displayed version number may not change significantly even though the vulnerability has been patched. Administrators should review package changelogs and installed RPM versions rather than relying solely on php -v. [computingf…rgeeks.com], [php2shell.app]

Verify Your System Is Patched

After updating, verify your installed PHP packages:

rpm -q php-common

Or review the package changelog:

rpm -q --changelog php-common | grep CVE

If your repository updates are current and the CVE references appear in the changelog, the PHP2Shell fixes have been applied even if the PHP version string still shows 7.4. [php2shell.app]


IMPORTANT: PHP 7.4 is officially end-of-life upstream. While AlmaLinux, Rocky Linux, and ViciBox may provide backported security fixes, organizations should develop a migration plan to PHP 8.2 or newer as soon as practical for long-term security and support. [computingf…rgeeks.com], [almalinux.org]


What Administrators Should Do Right Now

  1. Identify all servers running PHP.
  2. Update PHP packages immediately.
  3. Restart PHP-FPM and/or Apache after patching.
  4. Verify the running version.
  5. Review logs for suspicious requests dating back to October 2026.
  6. Prioritize systems using Apache mod_php, as PHP developers have identified them as the highest-risk deployment model. [hackread.com], [notebookcheck.net]

Final Thoughts

Unlike vulnerabilities that affect a specific CMS or plugin, PHP2Shell targets the PHP runtime itself. This means WordPress, Laravel, Drupal, Joomla, VICIdial, custom applications, and virtually any PHP-powered application may be exposed if the underlying PHP installation remains unpatched. The safest course of action is simple: update PHP immediately and verify that your services have restarted successfully. [almalinux.org], [phpvulnera…lities.app]

Chris aka carpenox

August 2024 VICIdial Security Update

Security Update needed

August 2024 VICIdial Security Update

Please read this carefully as it contains important information regarding the security of your VICIdial system.

The ViciDial Group recently conducted a security audit of VICIdial which resulted in the identification of severe vulnerabilities. We have patched these and submitted these changes to the code-base. Any system that is at SVN version 3848 or greater already has them. If your system is below that version, we strongly recommend that you upgrade to address these concerns. If you would like us to upgrade your system for you, please send a new email to support@cyburdial.com and put “Security Upgrade” in the subject. A typical upgrade takes about 15 to 30 minutes of support time. You can see the seriousness of these exploit here: https://packetstormsecurity.com/files/181461/VICIdial-2.14-917a-Remote-Code-Execution.html
https://packetstormsecurity.com/files/181460/VICIdial-2.14-917a-SQL-Injection.html

To find the SVN version of your VICIdial installation, log into your administator account and go to “Admin”, then click on “System Settings”. It will be the second line from the top, on the right, under “SVN Version”.

Please note, if your setup contains customizations done directly to VICIdial’s code, further review of your system will be needed as it may not be possible to upgrade you.

image

You can update your SVN by following this article: How to – Update your Vicidial version with subversion

Chris aka carpenox

How to – Use Firewalld via command line

Robots trying to hack in

How to – use Firewalld via command line

This short post is just going to briefly go over the more common commands you need in order to manage firewalld and make sure you keep your servers safe. This firewall works in conjunction with the dynamic portal for ViciDial as well as the built in whitelist initially named ViciWhite in the IP list area in Admin.

Dynamic portal
Dynamic portal

Systemctl and Firewalld

Enable firewalld

This makes sure that firewalld will be started automatically with the server.

systemctl enable firewalld

Start firewalld

After the firewalld service is enabled, you’ll need to start it manually the first time. This is how you would manually start firewalld if it were not already running.

systemctl start firewalld

Stop firewalld

When troubleshooting rules and connection issues, you may need to stop the fireawlld service momentarily. You can stop the service with the following command.

systemctl stop firewalld

Restart firewalld

If for some reason, you need to restart the service, you can do that with the systemctl restart command.

systemctl restart firewalld

Firewalld status

Checking the status of the service gives us the most meaningful and informative output. Here you can see whether the service is enabled, running, failed, or anything else.

systemctl status firewalld

In this example output, you can see that the service is enabled, active, and running on the server. If it were not running or in a failed state, this would be displayed.

[root@alma ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-01-22 22:50:32 EST; 1h 0min ago
Main PID: 808 (firewalld)
CGroup: /system.slice/firewalld.service
└─808 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Managing Firewalld and Configuring Rules

Now that we have firewalld running, we can get down to set the configuration. We can open ports, allow services, whitelist IPs for access, and more. In all of these examples, we include the –permanent flag. This is important to make sure a rule is saved even after you restart firewalld, or reboot the server. Once you’re done adding new rules, you need to reload the firewall to make the new rules active.

Add a Port for TCP or UDP

You do have to specify TCP or UDP and to open a port for both. You will need to add rules for each protocol.

firewall-cmd --permanent --add-port=22/TCP
firewall-cmd --permanent --add-port=53/UDP

Remove a Port for TCP or UDP

Using a slight variation on the above structure, you can remove a currently open port, effectively closing off that port.

firewall-cmd --permanent --remove-port=444/tcp

Add a Service

These services assume the default ports configured within the /etc/services configuration file; if you wish to use a service on a non-standard port, you will have to open the specific port, as in the example above.

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http

Remove a Service

As above, you specify the remove-service option, and you can close off the port that is defined for that service.

firewall-cmd --permanent --remove-service=mysql

Whitelist an IP Address

To whitelist or allow access from an IP or range of IPs, you can tell the firewall to add a trusted source.

firewall-cmd --permanent --add-source=192.168.1.100

You can also allow a range of IPs using what is called CIDR notation. CIDR is outside the scope of this article but is a shorthand that can be used for noting ranges of IP addresses.

firewall-cmd --permanent --add-source=192.168.1.0/24

Remove a Whitelisted IP Address

To remove a whitelisted IP or IP range, you can use the –remove-source option.

firewall-cmd --permanent --remove-source=192.168.1.100

Block an IP Address

As the firewall-cmd tool is mostly used for opening or allowing access, rich rules are needed to block an IP. Rich rules are similar in form to the way iptables rules are written.

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' reject"

You can again use CIDR notation also block a range of IP addresses.

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.0/24' reject"

Whitelist an IP Address for a Specific Port (More Rich Rules)

We have to reach back to iptables and create another rich rule; however, we are using the accept statement at the end to allow the IP access, rather than reject its access.

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

Removing a Rich Rule

To remove a rich rule, use the option —remove-rich-rule, but you have to fully specify which rule is being removed, so it is best to copy and paste the full rule, rather than try to type it all out from memory.

firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

Saving Firewall Rules

After you have completed all the additions and subtraction of rules, you need to reload the firewall rules to make them active. To do this, you again use the firewall-cmd tool but using the option –reload.

firewall-cmd --reload

Viewing Firewall Rules

After reloading the rules, you can confirm if the new rules are in place correctly with the following.

firewall-cmd --list-all

Here is an example output from the –list-all option, you can see that this server has a number of ports, and services open in the firewall along with a rich rule (that forwards one port to another).

[root@alma ~]# firewall-cmd --list-all
public (default, active)
interfaces: enp1s0
sources: 192.168.1.0/24
services: dhcpv6-client dns http https mysql nfs samba smtp ssh
ports: 443/tcp 80/tcp 5900-5902/tcp 83/tcp 444/tcp 3260/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="192.168.1.0/24" forward-port port="5423" protocol="tcp" to-port="80"


Hopefully this will help a lot of you that end up just not using a firewall at all because it intimidates you not knowing how to use it correctly. Well, I’ve just eliminated that excuse, so now I want to see more of you securing your servers and dialer systems. Here is a few articles to get you started in the right direction.

This will show you how secure OpenSUSE LEAP
https://dialer.one/how-to-scratch-install-the-dynportal-on-centos/?amp
Securing CentOS, Alma or Rocky Linux

Here are some more articles in relation to VICIdial security for your servers

How to – Use the built in Dynamic Portal for Vicibox
How to – Turn on IP whitelist in Vicidial
How to – Use one dynamic portal for whitelisting and have it sync across an entire cluster
How to – Fix the firewall on Vicibox10


That’s it for this article, hopefully you guys take this serious because hackers, especially ransomware thieves are targeting dialer servers in particular for their schemes, such as using the VoIP to call their victims to either trick them into downloading files or threatening them over the phone with blackmail or other means. BazarCall is one of the more well known tools thats being used by the ransomware group called Ryuk.

URGENT UPDATE REQUIRED – ViciDial Security Vulnerability

security update

URGENT UPDATE REQUIRED – ViciDial Security Vulnerability

The ViciDial Group has released a warning for any SVN version below 3583, if you are below this version, update your system immediately. You can do so by following this article for SVN update.

image
ViciDial versions below 3583 are Vulnerable!

I hope everyone takes this seriously, or your data may be hacked or minutes used on your VoIP, or worse.

Chris aka Carpenox

Table of Contents – Knowledge Base

CyburDial

I am carpenox from the Vicidial forums and I enjoy helping our community, of which I do free of charge, however my one on one time helping people out I do have to charge for my time in order to keep this going. If my articles have helped you out and you’re making money now because of my help, please think about donating to the cause so I can keep this blog going. Here is a link to donate through PayPal.

Check out all of our social media platforms -:- https://linktr.ee/CyburDial

image 101361114 15620149

Join us on Discord: https://discord.gg/jt8sNvJM

image 101361114 11793737

Table of Contents

10 Latest Posts

Information

image 101361114 14092462
HIPPA Compliance
HIPPA Compliance

Book time with carpenox now

ViciDial Scratch Install Instructions

image 101361114 11793737

Troubleshooting ViciDial

How To’s

Security

image 101361114 13942202

STAYING COMPLIANT

image 101361114 13942211